1. What is the issue? Please be detailed.
I uploaded a list of locations to an entity list, pre sorted in the order I wished the choices to display.
The list in Central shows row 1 at the bottom as entry 1, and the last row at the top, so the file was read from top to bottom.
When I use this entity list in a Select, the order is reversed, displaying them in the order they were added to the entity list, most recent first.
I need the ability to sort choices, be it A-Z / elevation / priority / incomplete first / smallest to largest (for proper rendering of polygons on map to still allow selection without blocking) or any other method to aid in usability. Currently with CSV choice lists I generate the list in the preferred order and then create the file.
Knowing how they are processed means reverse sorting the list before uploading will work, but this doesn't work for items created at different times or where the preferred order will change as the survey progresses.
I can't see how the choices can be ordered based on any value in the entity list, there's nothing in the docs or on the forum that I could turn up on sorting entities or choices, only that they are now sorted by creation order:
We're currently working on supporting offline Entities and as we design how Entities are stored on-device for offline creation and updates, we are considering an eventual sorting requirement.
On a note as I was browsing the doc and I have not seen this info on the forum, you can already add a sortby property for entities, it will order your entities when using search (the column just needs to NOT contain empty values). You can reorder manually if you have a small amount of entities. Obviously if you want something more dynamic (i.e. ordering alphabetically while managing a high number of entities), my guess is that you would have to edit this property in all entities using the API, after new entities have been created.
I found reference to this in the XLSForm docs after you posted it, but sortby isn't mentioned in the ODK docs so I hadn't seen it before!
I don't use search for my choice filtering and prefer to use instance. It appears that a search can have at most two levels of filtering only, with the first allowing contains/startswith/endswith/matches and the second only being an exact match, which isn't as flexible as instance lookups that allow other types of filtering and more than two constraints.
I guess sortby is specific to search currently so including that column wouldn't be useful (yet), but perhaps some of my filters are simple enough to accomplish with search so I should start adding it to my entity lists. As sortby is numeric I would have to manually edit or use the API to correctly sort lists that are A-Z
Oh, that’s a good point - Apologies I ran many tests over the weekend and mistakenly thought sortby was working with search (which I regularly use with entities) because I had seen it working with search() while doing some testing, hence the ambiguity. I admit this makes it much less useful for entities since you the search() syntax is not really "best practice" and is not compatible with certain ODK features, such as choice_filter.
So to be clear, the first syntax search(...) used with select_one / select_multiple leads to a sorted list (but is not best practice), while the second syntax search used with select_one_from_file / select_multiple_from_file does not
I didn't use sortby. Instead, I inverted the csv prior to create via pyODK. The orders in the entity list will be the opposite of csv (002, 001, 000):
The choice options order as follow:
000
001
002
I also try to create individual entity manually using registration form in the order of 000, 001 and 002.
The order in the entity list appeared as 002, 001, 000.
Entire entity list will look as follow:
manual - 002
manual - 001
manual - 000
pyODK(create)- 000
pyODK(create)- 001
pyODK(create)- 002
Surprisingly, the choice order for manually created entity is 000, 001 and 002.
It seems like there is a difference in order behaviour between entity created manually vs entity created via pyODK. I have not try csv import, I think append entity using csv import will likely behave the same as pyODK create entity.
