Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    5.1d 5.0p BatchUploader Sort is strangly broken

    Hi Isomorphic,

    please download the csv file from the BatchUploader sample and upload it to the widget.

    Now click the ListGrid Header quite often to resort. In an unclear manner all validation errors disappear (or reappear) on sorting.
    Expected behavior is that all the validation errors stay in place, only the records are resorted according to the value.

    This happens in the 5.0p sample as well as in my 5.1d BatchUploader and is very confusing.

    Best regards
    Blama

    #2
    Just a note to say we do see this behavior and have a developer taking a look.

    Regards
    Isomorphic Software

    Comment


      #3
      We've made a change to address this. Please try the next nightly build (Oct 30)

      Regards
      Isomorphic Software

      Comment


        #4
        Hi Isomorphic,

        this is fixed for me using SNAPSHOT_v10.1d_2015-10-30. Thank you for the fast reaction.

        It does take the validation_failed_icon as part of the field value, making error rows always appear first or last (most likely because of a "<" in the beginning?).

        For me, the ListGrid also does not sort on columns where all rows have an error. Perhaps you take only the first x characters for a client-side sort and these are always the same for erroneous rows?

        The remaining bugs are not that important for me, but it would be nice if they get fixed as well.

        Best regards
        ​Blama

        Comment


          #5
          Hi Blama,
          What's happening here is this: The validation errors reflect essentially "pending edits" on the grid data. The listGrid sorting mechanism does not take these into account - instead sorting is performed based on the underlying record values. If you correct the errors, the edits you make will be saved (locally) to the grid's data object, and used for sorting.
          An argument could be made for sorting by edit values instead of underlying record values, but in the "normal editing" scenario it usually isn't desirable as if a user edits a sorted field we don't want the record to "jump out of view" to a new sorted position in the data.
          We will make this clearer in the documentation around edit values and sorting to avoid future confusion on this sort of thing

          Regards
          Isomorphic Software

          Comment

          Working...
          X