Incorrect FB# sorting now that Apple has passed FB10000000. New items are on page 24, not 1.

[bradtchapman]

I just added an FB with 8 digits that starts with 1001 and it isn't on page 1, but way down on page 24. I also found other FB#'s down there that appear to have been opened recently.

If the "date" field isn't populated consistently by users, can you still ensure that FB's are sorted by date when it was added to the OpenRadar database, instead of using a pure alphanumeric sort? Otherwise, FB10027879 comes before FB264382.

See screenshot. Thanks!

[futuretap]

I suggest either to sort numerically or by submission date. Just this small change would make Open Radar immediately useful again!

[Artoria2e5]

Right now it is pretty alnum: https://github.com/timburks/openradar/blob/4645c4b513c5133ddb3a0f506c8ee3ccf563df74/python/openradar/web.py#L55

The db has a column called number_intvalue that we can use to sort by value: https://github.com/timburks/openradar/blob/4645c4b513c5133ddb3a0f506c8ee3ccf563df74/python/openradar/models.py#L43

There is one big "INVALID" entry out there though. No idea how it got there; probably it won't get a number_intvalue.

[Artoria2e5]

Ah yikes, the number (actually a string) sorting thing is forced by #43/#44, just changing it back won't work. I guess we can add an additional property (column) so we can use two properties in order by: order by is_fb desc, number_intvalue desc.

I don't know what kind of sorcery is required to change table shape in GQL. There's also a bunch of deprecation notices on the Python 2 GQL documentation I don't want to look at.