Redmine

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?

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.

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?

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.

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.

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.

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

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

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 ?

+1 for including this in 0.9

I would really like to apply this patch, but don't want to revert to r2065.

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.

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 !

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.

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

+1 for including this feature in 0.9

I need this feature, too. +1 for including this feature in 0.9

+1 we need this. is there a way to vote on issues instead of writing stupid "+1"? :)

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 :(

ciaran jessup wrote:

[...] could've saved myself a coupla hours work had I spotted this previously :(

Hi !

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

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

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

+1

+ 1 For the patch into trunk

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

I would love to see this feature rolled into the core product.

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

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.

+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

+1

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

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

+1

+1 Would be a great addition.

+1.

+1 (yes this is a important feature) :)

I'd like to point all of you to issue #6914 . Enough with the "+1" already!

+1

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

+1

+1

+1

+1

+1

+1

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.

+1

+1

FFS, can't you guys fix #6914? I've had enough of those moronic '+1' comments.

+1 for this feature

Is there some problems on this? technical or marketing consideration? Thanks!

+1

This would be a really important feature for us.. being able to select multiple affected and target versions.

+1

+1

It would be a really useful feature (instead of a block to adoption this great app)

+1

Could it be possible some skilled Dev update the patch to make things work in 1.2.1?
This is a highly anticipated feature.

@2trunk!
+1

+1

+1 We also need to be able to create multichoice custom fields.

+1

+1

Could any of the Redmine folks enlighten me why has this been not implemented the last 3.5 years?

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'

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?

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.

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.

Hi,

What are the issues that are stopping this request from being implemented and added to a formal release?

Cheers,
Matt

+1 please add this to formal release

+1

+1

+1

+1

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?

+1

This is great news, thanks.

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 ?

Jean-Philippe Lang wrote:

Feature added in r8721.

Question: existing list could be converted to "Multiple values" behavior?

pasquale [:dedalus] wrote:

Question: existing list could be converted to "Multiple values" behavior?

auto-reply: yes! because r7434 ;-)