v7.10.2.2
I noticed something strange in query results yesterday. Lots identified as a taxon which had its Preferred Taxon updated in our Taxon Tree a few months ago are still bearing the previous Preferred Taxon. Both taxa occur in query results as the Preferred Taxon for the same determined Taxon.
This is incorrect behavior. It appears that the user can force the update to the new Preferred Taxon by updating the current determination record (in any way, even saving a version with no change committed) for an affected lot, but this should be done automatically when the Taxon Tree is updated.
Not sure exactly how long it’s been like this, but I just noticed it. I can see that I changed the synonymy on 2024-11-09, and all records created or modified since then have the correct Preferred Taxon, whereas all records with determinations created or modified before that date have an incorrect Preferred Taxon. I’ve found records with this issue as far back as August, so it has nothing to do with 7.10.2, and has likely been the behavior since I have started using specify, I just hadn’t noticed until now.
See below: a query performed today, showing the same Taxon ID having two different Preferred Taxon IDs in the same result set.
Upon committing an edit (entering a space in “Verbatim Determination” field, immediately deleting it, and hitting save), the Preferred Taxon is correct:
I was testing yesterday whether I could brute-force an update by using batch edit on records which are currently displaying the wrong Preferred Taxon for their determined Taxon. The logic here being that the Preferred Taxon in the determination table is a static/cached value that only changes when the determination itself is updated, and that batch edit does the right kind of update to invoke the change in PreferredTaxon. (Seems similar to how sometimes Excel formulae in cells formatted as text can get “stuck” like this and you need to edit the contents of a cell and commit a change in order to force a calculation.)
So I used batch edit to add a value of 1 to an unused field in the Determination table (integer5), and it fixed the problem for these lots. The point stands though that this should not be necessary to manually change. A synonymization should automatically change all records in the determination table, there should NEVER be two different PreferredTaxon ID values for a given Taxon ID in the data displayed/exported by Specify.
After investigating this, I found that the issue occurs whenever the Preferred Taxon field is manually changed on the Taxon form. Thank you for sharing your method for resolving affected records. For now, you can work around the issue by using the Synonymize tool in the Tree viewer, as this updates the Determination record. I have written up a bug report for you on Github–could you please take a look and let us know whether it covers everything?
Aha! I didn’t think of that, but that is totally what I did for those records. I was trying to figure out why some synonymizations changed records and others didn’t. I suppose then that one could de- and re- synonymize affected taxa using the Synonymize tool rather than doing a batch edit to fix them, as that wouldn’t be limited to under 5000 records at a time like batch edit is.
The github description looks good, thanks for that! 2 comments:
I would perhaps edit the Expected behavior bit for clarity:
The Preferred Taxon field should automatically be updated on Determination forms whenever the Taxon’s Preferred Taxon is changed in the Taxon form.
A brief aside, you can actually increase the number of records that Batch Edit can use in a single data set via User Preferences if you are interested!
.