Some incorrect workflow id / subject_id combinations in stored classifications

[camallen]

I'm not 100% sure why but there are classifications for a subject_id that have a different workflow_id to the assigned subject_set & set_member_subject links. This is throwing off the retirement counts for the subjects. It might be related to here specifically it's just using the first workflow that is returned from the API and not a specific one via a config file (i assume that @rogerhutchings planned to only have 1 workflow so that makes sense). BUT this should drive the subjects via cellect so only those workflow's subject should come back.

Might be local storage and api response ordering related but i think the serialiser maintains order or the link keys (I may very well be wrong). If not then the first array index may lead to a different workflow ID for previously locally stored subjects and thus the classifiation annotation may have the wrong workflow.

It could also be the backend and the way subject sets were setup / changed but i can't see it in the version history.

SO I am not sure..but there is definitely an issue where classification annotations are being stored for incorrect workflow_id & subject_id combinations and thus the counters used in retirement aren't working properly.

[rogerhutchings]

Is this still happening @camallen?

[camallen]

I assume not, this is pretty old. Where are you getting the workflow ids for classification submission?

[rogerhutchings]

From the project info returned by the API

[camallen]

should be fine then.

[rogerhutchings]

:+1: