Preserve task ordering between the API and UI code

[camallen]

I was looking into fixing the FEM dropdown task classification exports and noticed the annotation values have changed from the option value in the workflow to the index of the selected value from the UI element.

This change from the PFE format was a little unexpected but after a chatting with Jim & Shaun they summarised this change as a simpler format that mirrors how the single answer (simple) task annotation format works.

My only concern with this change is we now have an ordering dependency between the API workflow task option ordering and the UI HTML select option ordering. E.g. the FEM code loads a WF from the API and has wf.task.options = [{option1, option2, option3}] but some code between the workflow store (i think) and the UI HTML element wiring happens to reorder that list to say [{option3, option2, option1}]. Then when i reconstruct the annotation details API side for say annotation index value 0, the results will be option1 but the UI really showed option3 to the user.

Historically in PFE land we used the explicit task option value codes (from the API workflow) in the classification annotation values, this ensured we could reconstruct the annotation regardless of how the UI displayed the options.
My concerns were alleviated as currently the HTML task select ordering is preserved through the map function via

front-end-monorepo/packages/lib-classifier/src/plugins/tasks/SimpleDropdownTask/models/helpers/legacyDropdownAdapter/legacyDropdownAdapter.js

Lines 11 to 12 in af5483c

	const options = menu.options['*']
	newSnapshot.options = options.map(option => option.label)

However I can see a use case request for an ordered dropdown (alphabetically via the translation labels) coming from a project team. Perhaps the (new?) FEM developer doesn’t understand this implicit ordering dependency and thus sorts the option order before rendering in the UI element and thus breaks the ability for downstream services (panoptes exports, caesar, aggregation code etc) to correctly reconstruct the volunteer answers.

Noting, when I read the ADRs for the dropdown task it didn’t mention that ordering of the task options needs to be preserved to ensure the correct recording of answers.

I’m not sure what tools in FEM land are using this indexing strategy for annotation values but it’s worth while ensuring folks are aware of the hard dependency with the ordering of the original API representation of the tasks and the corresponding annotation values.