Bug: Filtering Multiselect ignores order

[jordanmaguire]

Hi team,

So the js for filtering multiselect ignores order when associated_collection_cache_all is false.

Here's the setup:

Let's say our model has the following association:

has_many :facilitator_memberships, dependent: :destroy, inverse_of: :user
has_many :clubs, through: :facilitator_memberships

and our RA configuration has the following:

edit do
  field :name
  field :username
  field :email
  field :password
  field :clubs do
    associated_collection_cache_all true
    associated_collection_scope do
      Proc.new do |scope|
        scope = scope.order(:name)
      end
    end
  end
end

Keep in mind that associated_collection_cache_all is required to be true here otherwise the user is presented with an empty result set when they load the page.

Whereas I'd like them to see:

What's the problem?

Well, the js for the filtering multiselect stores the data about the options (id and content) in a hash and builds the options from that hash when a search is made.

This has the unfortunate side affect of dismissing the order initially put on the page when a search is made. IE:

What's the solution?

There are three solutions that I can look into:

1. I can turn off associated_collection_cache_all. As mentioned above, that has the side effect of making the interface extremely hard to use.
2. I can make my own interface for these fields and override it using the partial option.
3. I can patch RA so that the filtering multiselect works.

Option 1 is unacceptable to me. The user experience is paramount.

Option 2 is barely palatable. It is a bandaid solution.

I'd rather Option 3, so every page I have with these fields will maintain order.

Option 3: Fixing Filtering Multiselect

There's two ways I can fix the multiselect.

1. Maintain the current solution, but override the cache so that it stores order as well.
2. Get rid of the current solution, replace it with something simpler that shows/hides options based on whether they match the search params. Rather than building them all from scratch each search.

In my mind, solution 2 is the better option. The current solution has so much code to do such a tiny amount of work. There's no need to rebuild all the elements every time a search is made.

All you need to do is just search over the options and disable/hide them if they don't match the given parameters.

What I need from the maintainers

Before I invest some hours of work in this problem, I'd like to know that the solution I'm intending to implement will actually be considered for merging.

Further, I'd like to know what kind of test coverage you would expect for such a change.

Let me know.

These changes should be able to resolve this issue

EDIT

Another side effect of the current implementation is that order is ignored in the right box as well:

[mshibuya]

Fixed by #2412, thank you for detailed report.

[jordanmaguire]

Awesome. Thanks!