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
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.
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.)