SelectMultiple _has_changed assumes data and inital are in same order

[Anssi Kääriäinen]

The _has_changed method assumes data and initial are in same order:

for value1, value2 in zip(initial, data):
    if force_unicode(value1) != force_unicode(value2):
        return True

This seems like a dangerous assumption, because initial and data might come from different sources. For example if you override the queryset for ModelMultipleChoiceField to have custom ordering, initial and data returned from the HTML form will probably differ in order. And by default m2m initial data in model forms is retrieved without any ordering, so it is just assumed that every time the query is run, the data will be retrieved in the same order. This is of course wrong.

[Daniel F Moisset]

Looks like a legitimate bug

[Daniel F Moisset]

Added an attachment based on akaariai's, but with a more pythonic way to compare the sets.

[Jannis Leidel]

(In [14887]) Fixed #14158 -- Fixed SelectMultiple._has_changed to not assume same order of data anymore. Thanks, akaariai and dmoisset.

[Jannis Leidel]

(In [14907]) [1.2.X] Fixed #14158 -- Fixed SelectMultiple._has_changed to not assume same order of data anymore. Thanks, akaariai and dmoisset.

Backport from trunk (r14887).