Errors/discrepancies in getting results from API / identifications / identifiers

[astra_the_dragon]

First of all, please forgive me if I’m not fully able to explain myself. I learned to use the API just last week with help from @pisum . Once I’ve got a better grip on the issue I may fill out a proper bug report.

I’m using https://api.inaturalist.org/v1/docs/#!/Identifications/get_identifications_identifiers
tiwane helped me export the list of Forum users who had voted to sign up for the ID-a-thon. I copied the list directly into user_login, and for the most part got my expected result.

There were a few discrepancies.

One user was not returned, and had zero IDs. I don’t know if this is a bug, but I would have expected their data to be returned with the result for count as zero, or an error message of some sort.

Three users’ data were returned correctly, but the name attached to the data has been changed: e.g. I input aastone and got back results for abigstone who does appear to be the same person. I had to do a manual search to figure this out, because the original input was not reflected anywhere in the resulting JSON. Again, not necessarily a bug, but confusing.

Three users’ data were not returned at all, though I was able to find the users on iNat through manual search. There was no error message. The commonality between these three was that their Forum username (which I copied exactly into the API endpoint) was capitalized – e.g. SteveMcBill or Oliverc29. As I did not find instructions that the login names must be all in lowercase, either this should be clearly explained on the page, or this is a bug.

**
I end this with a minor, unrelated plea: if your Forum username is different from your iNat login name, please link to your profile from the Forum and/or provide some other way to easily link between the two accounts. Please and thank you. You’re giving me headaches and the ID-a-thon hasn’t even started yet.

[pisum]

@astra_the_dragon

One user was not returned, and had zero IDs. I don’t know if this is a bug, but I would have expected their data to be returned with the result for count as zero, or an error message of some sort.

i don’t see this behavior as a bug, nor do i see it as unexpected. (no need to have the server return extra data.) if you have a full list of your participants, then you can just merge it with the results coming out of the API. here’s an example of a SQL query that could do that for you:

SELECT A.user_login, B.count
FROM all_participants A
LEFT OUTER JOIN top_identifiers B
  ON A.user_login = B.user_login
ORDER BY B.count DESC, A.user_login ASC

@astra_the_dragon

Three users’ data were returned correctly, but the name attached to the data has been changed: e.g. I input aastone and got back results for abigstone who does appear to be the same person.

this is sort of a bug, i think. this endpoint allows you to filter for a user using two different parameters – user_id and user_login.

the user_id parameter actually filters by the numeric user id, but it’s smart enough that if you give it a user login (a non-numeric value), it’ll look up the appropriate numeric user id and use the numeric id to filter. the problem with the user_id parameter is that if you feed it an invalid user id or login, it’ll return an error (as opposed to just an empty result set).

the user_login parameter filters for identifications by user login, but this is problematic because it looks like each identification record is stored with the user login at the time of the identification. so user_login=[old login] will return only identifications made when the user had the old login, and user_login=[new login] will return only identifications made using the new login. you can see this by comparing the results of these 3 requests:

• https://jumear.github.io/stirfry/iNatAPIv1_identifications.html?user_id=abigstone
• https://jumear.github.io/stirfry/iNatAPIv1_identifications.html?user_login=abigstone
• https://jumear.github.io/stirfry/iNatAPIv1_identifications.html?user_login=aastone

so to get the data you need from the API as it exists now, you need to filter using the user_id parameter, and you need to make sure you don’t feed it any invalid user ids/logins.

if i were designing things, i wouldn’t record user login at the time of identification. that seems unnecessary, since user id doesn’t change and is recorded on the identification record, too. filtering using the user_login parameter should work just as if you input a user login in the user_id parameter – except i think it would be better if the API would just return no results for bad user ids/logins instead of failing with an error.

another way to address the problem here is to go into every table where user login is stored and change the recorded old user login to the new user login whenever a user changes his or her user login. this is sort of a clunky approach, but it would work.

@astra_the_dragon

Three users’ data were not returned at all, though I was able to find the users on iNat through manual search. There was no error message. The commonality between these three was that their Forum username (which I copied exactly into the API endpoint) was capitalized

although the forum allows you to have mixed case logins, the main system nowadays enforces lower case only. there are some mixed-case legacy user logins, however – see https://forum.inaturalist.org/t/issue-with-2-same-usernames-but-different-capitalisation/11373/4. so that’s probably why the user parameters don’t automatically translate mixed case inputs to lower case, in case you actually need to differentiate between two similarly named but differently cased user logins.

for your use case, it’s probably best just to translate any mixed case logins to lower case before feeding them to the user_id (or user_login) parameter. (at some point, it probably would make sense to have the system do the translation from mixed case to lower case inputs, but not until the legacy mixed case logins are cleaned up, i think.)