Please fill out the following sections to the best of your ability, it will help us investigate bugs if we have this information at the outset. Screenshots are especially helpful, so please provide those if you can.
Platform (Android, iOS, Website): Android app
App version number, if a mobile app issue (shown under Settings or About): 1.26.3 (533)
Description of problem (please provide a set of steps we can use to replicate the issue, and make as many as you need.): After uploading a bunch ob observations, initially everything seems fine and finished successfull. When you return to your observations tab in the app after some time, it tells you there is 1 observations to sync (even though this exact observation has been completely uploaded with all pics, and is already availabye on the website). if you press sync, which you’ll have to do sooner or later if you want to add new observations, it will restore your very first ID on that observation, discarding all of your later identification work.
This bug has been around since i started using iNaturalist and its one of the most annoying ones. It happens quite ofthen and its especially bad if you dont notice that your IDs have changed. Its time to fix it.
Pretty much the same problem here: same platform, version, also for as long as I can remember. One difference is it will throw in the 1st ID after I add or edit a comment on the latest one. It’s doubling annoying that I can’t delete this erroneous throwback. Here’s one example out of dozens: https://www.inaturalist.org/observations/105985766. Thanks @jf920
I have also had this issue intermittently on Android for a long time. It is most common when I create an observation on the Android app, then later edit and identify it on the desktop website.
Usually the app’s erroneous ID matches the first one I originally made. However, yesterday the app auto-added an identification at the Order level, to match the Community Taxon from a few hours earlier in the day. Nobody else had made an Order level ID to agree with, and by the time this occurred the Community Taxa had already advanced to the Species level. https://www.inaturalist.org/observations/106098566
The problem: I upload an observation, with a genus ID. My ID is then refined by an expert to species level. I agree with that. Next thing I know, the expert is complaining that I’ve reversed my ID back to genus level. This has happened about 5 times.
This morning I received a disagreement ID for an observation, so agreed with the new ID. I then decided to take another photo of the subject and uploaded it via the app. I soon noticed that my agreement with the correct ID had been withdrawn and the incorrect one added back. https://www.inaturalist.org/observations/141271089
So, is this an app problem? I can’t remember if I was using the app when the problem occurred before. It’s rather embarrassing …
I just checked, going to edit an observation through the website on PC displays the ID consensus for a second, then switches to the original ID. I haven’t submitted the edit (I could if it helps, but it should be easy enough to reproduce) but I’d expect it to mean the problem is not confined to the app.
Yes, sometimes a page does take a couple of seconds for the ID to update.
Which version of the app are you using? If you can recreate the issue and post screenshots or a specific sequence of steps that could help.
On a side note, in general users should only agree with other users’ IDs if they can independently confirm those IDs. An original ID of genus is absolutely fine if that’s the level at which a user is able to ID based on their own expertise and won’t cause issues as it doesn’t disagree with other finer/more specific IDs.
Hmm, I think I’ve noticed this happening as well (on the web, but could have been from app uploads). A user IDs from genus to species level, then it seems like they’ve taken it back to genus, then species and then genus again. Seen it happening a few times now, but wasn’t sure if it was a bug as some of the users looked new
Correct, it was the second example I gave. I used this example because it was the first time that I immediately noticed the problem occurring and realised that it was directly after editing the observation via the app.
Version 1.28.8 (561) has been released to everyone, and should prevent this. I’m going to leave this thread open for a few days and would love it if anyone can test it and provide feedback.
So far it has not happened to me again. I cant really test wether its gone since it only happened to me seemingly at random, but so far its looking good.
Since no one else has reported this either on recent versions, i guess we can call this fixed.
Thank you for looking into it.