Collection projects with users filter missing link back to project from observations

Bug Reports
1

Hi. Collection projects that have a rule that requires observations to be from specific members seem to all be missing links back from those observations to the projects to which they belong, even though those observations otherwise show up on the project page and can be located by using a project filter on the search form. Details below.

Our Discord member observations

Associated with the Discord server we have some iNat Projects which are collection projects that specify among the rules that observations must be from a selected list of users (i.e. members of the Discord server). These have recently stopped showing their links back to the projects that the observations belong to on the observation pages themselves, even though the project pages continue to show all observations that match the rules for collection. Here are two of these projects in which we first noticed the issue:

Any random observation selected from either of these projects is expected to have the badge and link back to the project that contains it, but those are missing, e.g. this recent observation is in both projects:

and this much older observation is not in the yearlist project but is in the other project:

Neither observation has a link back to the Discord projects to which they belong.

Other projects than ours are affected

I thought at first that all collection projects were broken, but quickly discovered that many other collection projects do not have this issue. Then I traced it to the kind of collection project that we have, that I believe is relatively uncommon: most collection projects don’t specify that the observations must be made by specific user_ids. I then searched for projects with “member” in the name and randomly selected this one for comparison:

It exhibits the same bug. Clicking any observation in this project will show that the observation itself does not link back to this collection project, e.g.

Interference with ongoing code development

The timing of the problem is unfortunate, as I was in the process of rolling out features in the Discord bot we’ve been developing that made use of project_ids, and specifically, our own Discord project_ids. Because I was looking closely at the JSON data returned by the /v1/observations API call, and that was an unfamiliar way of looking at the data vs. just looking at the observation page itself on the web, I missed the forest for the trees. I thought somehow project_ids for collection projects were by design treated differently than for traditional projects!

For example, if you look at this record, you’ll note that project_ids is empty (i.e. []):

https://api.inaturalist.org/v1/observations/35052020

even though this record can be located within the project, e.g. by this search:

https://www.inaturalist.org/observations?on=2019-10-28&place_id=any&project_id=33276&subview=table&taxon_id=367176&user_id=bookworm86&verifiable=any

Once I got independent confirmation from other users around the same time that they started noticing the missing link back to the project from their observations, I finally clued in that we had a bug here, and not merely an API limitation.

Meanwhile, I can focus development efforts on another area of the code while we wait for the issue to be fixed.

Conclusion

I hope you can find the cause of and fix this issue soon.

Thanks, on behalf of all of us on the unofficial Discord iNat server.

2

This is expected behavior if the user has not joined the project:

If an observation meets the requirements of a project which the observer has joined, you will see a “badge” on the observation’s page

From https://www.inaturalist.org/pages/managing-projects#collection

Observations can potentially qualify for hundreds or thousands of collection projects, so we limit badges to only the projects which the observer has joined.

1 Like
3

@tiwane I am a member of the Discord projects in question (except for the other project which I furnished as additional evidence). So are the other members of the Discord server reporting the problem. What do you think is going on here, then?

In fact, I’m not just a member of those Discord projects, but am an Admin of both projects. I will inquire of other server members to ensure that other projects members who are not also Admins are also seeing the same thing and get back to you.

4

This old suncup observation: https://www.inaturalist.org/observations/2582774 shouldn’t be in https://www.inaturalist.org/projects/discord-inaturalist-yearlisting-2019 since it wasn’t observed in 2019, which is a requirement for the yearlisting project.

bookworm86, who observed https://www.inaturalist.org/observations/35052020 is not a member of either Discord project, so the project badges shouldn’t be on the observation.

Looking into the mycoflora one…

1 Like
5

The suncup one is not in the yearlisting. Correct. It should be in the other Discord project covering all years, however. Sorry if that was ambiguous.

The observation by bookworm86 is included in both projects because they are in the rules for inclusion in both projects. Whether or not bookworm86 follows the project should have no bearing on whether benarmstrong (or the other non-admin testers I have helping me) can see the links back to the projects they are in (provided they are logged in at the time) is my understanding. Please correct me if I’m wrong.

Do you need me to pick more failing examples that meet all of the criteria? I only showed two from dozens of observations that failed to show links back to the project, and many of the ones I checked are my own. I both am in the rules for inclusion in the project and follow the project, so they should definitely have the badges and links back to them, and yet do not. Here’s one of those:

This is my most recent contribution to the yearlist project. I follow the project and am in the rules for inclusion in the project, yet I see no badge and link back to the project. Nor did I see the badge & link for any other of my past observations that are in the project.

Re. “must be logged in” & how that affects bot code development, since the https://api.inaturalist.org/v1/observations/35052020 example is done without credentials in the header, strike that from the evidence. I realize now I will need to provide credentials on the API call with membership in the Discord groups in order for that to work the way I want it to.

But that does not rule out a problem in the other cases. The evidence so far is that at least for the admins of these groups, and also confirmed by two non-admins who are members of those projects, they clicked on the two links to observations at the top of my bug report and do not see links. One of those two also double-checked to make absolutely sure they were logged in with the login id on iNat that is a member of those projects, and that they are a member of both projects, and yet still did not see the links back to the projects within the observation pages themselves, just as I am seeing under the same conditions. The 2nd user was unavailable at the time I asked them to double-check those things for me. I’d be surprised given the evidence collected so far if they found anything that contradicted what we’ve seen so far, though.

6

Was https://www.inaturalist.org/projects/discord-inaturalist-yearlisting-2019 a traditional project that was converted to a collection project?

7

I doubt it. I will inquire and get back to you. So far as I know it has always been a collection project.

Also, I don’t think I made it clear before but this is new behaviour within the past week or two. The exact timeframe of the emergence of the issue is not yet established, but for sure during the summer we were seeing the links. We no longer do. The kind of project has not changed during that time period.

8

I think this affects more collection projects than just those that have a rule that requires observations to be from specific members. Some of my own projects have the same problem. I noticed a few days ago that new observations added by members weren’t displaying the icon for this project - https://www.inaturalist.org/projects/jewel-beetles-of-south-australia

I see now that all the included observations lack the link back, even those that definitely had it previously. The problem started straight after the most recent member joined - someone without any observations who wanted to do IDs. I assume this is entirely coincidental but mention it just in case.

Other collection projects of mine, of a similar nature, seem unaffected.

2 Likes
9

Can you please provide urls off example observations?

10

These are my own observations from the project, none of which show the project icon any more
https://www.inaturalist.org/observations?place_id=any&project_id=51463&subview=grid&user_id=388888&verifiable=any

11

I accidentally had the project_id numbers flipped. This is now fixed in my edit to the bug report above. Sorry if that confused anyone looking into the problem.

I have checked with the owner of https://www.inaturalist.org/projects/inaturalist-discord-server and have confirmation this was always a collection project. I’m reasonably confident the yearlist project was always a collection project too, but am still waiting to hear back from its owner about that. Observations from both projects exhibit the same issue with links back to the projects not appearing when a member of the project that is currently logged in is looking at the observation. This is, I hope, enough to rule out “was formerly a traditional project and converted later” as playing into the issue.

12

I have confirmed the yearlist project has always been a collection project from the start.

13

Same is happening to one of my projects – Biota of Trang An (https://www.inaturalist.org/projects/biota-of-trang-an). This project currently has only two members, but there are several observations by us that do not have the project badge on the observation page despite showing up on the project page. Two examples, both by the other current project member:

Would be great to get his resolved.> Blockquote

14

Could people that were seeing issues with collection project showing on observations page try again?

As for the API, non-traditional projects are not returned by observation details requests by default. It is fairly costly to reverse what is effectively the saved search of collection and umbrella projects. If you include an undocumented parameter include_new_projects=true you’ll get them in an element non_traditional_projects.

If there are lingering issues, could you please succinctly restate them? Thanks

1 Like
15

Everything looks OK to me now, thanks. I also had a few other users who were testing for me before check things out and everything is fine for them as well.

Though nobody responded to my request for correction on my understanding about bookworm86’s observation not showing a link, it is clear to me now I was mistaken about how that works; as Tony said - only collection projects to which the observer belongs are shown on their observations. And thinking that through, that makes sense to me, as everyone should see the same set of projects regardless of who you are (or even if you’re logged in).

As for the API & undocumented option, it sounds risky to write code depending on that. I’ll look into whether my plans for it can be modified to do without it.

Thanks,
Ben

16

All good here now, thanks.

17

Thanks - seems fixed!