Projects Function - some bugs/design issues?

In which Wildbook did the issue occur? ACW

What operating system were you using? (eg. MacOS 10.15.3) Win 10

What web browser were you using? (eg. Chrome 79) Chrome latest

What is your role on the site? (admin, researcher, etc) Admin

What happened? Testing of Projects functionality before training users I came across what I think are a number of errors/design issues/oversights as follows

After creating a Project and successfully adding Encounters to the project
https://africancarnivore.wildbook.org/projects/project.jsp?id=3a7c1169-127a-4641-a800-a54d2e816f16

When I then went to run matching the system allowed/attempted to match

An encounter with no annotations
https://africancarnivore.wildbook.org/projects/project.jsp?id=3a7c1169-127a-4641-a800-a54d2e816f16

An encounter with only a Part annotation
https://africancarnivore.wildbook.org/encounters/encounter.jsp?number=02416be8-cad7-46ec-88a3-86175319ad4c

In addition, when I went to an Encounter with a known ID and viewed the Matches, the system did not filter encounters by Project even when I selected the Project in the dropdown on the Match presentation page
https://africancarnivore.wildbook.org/iaResults.jsp?taskId=7d767b83-0bee-467c-bcff-b28f531844d8&projectIdPrefix=PM-###

What did you expect to happen?

No annotation - cannot kick of matching
Part annotation only - cannot kick off matching
When I select Project in Match Results I should only see Encounters from within the Project

What are some steps we could take to reproduce the issue?
See links above and feel free to use Project data provided to test as this is personal (not user) data

FYI
@tanyastere
@ACWadmin1
@jason

We have two design concerns and a bug here.
An enhancement to projects would be to restrict the annotations that have “start match” available to those that have an iaclass configured for matching (necessary to go this broad because some species match only on part (turtles) and some on only body (dogs) and some on both (sea dragons)).

I would consider this a feature request because it is about preventing user error, but it isn’t broken. Some organizations want to work with non-matchable data in a project, so those need to be viewable from a project. Users can verify from the project-view if the encounter they are observing has a configured iaclass by clicking “View Match”, which expands out a panel that includes the image and the relevant matching metadata.

The bug, however, is exactly what you reported. I went through the link you provided and there is an encounter in the list that is not in your project. We’ll get on that soon, tracking it under WB-1519.

Thanks Tanya

I understand the “design” issues and thank you for the bug fix followup.

Perhaps the check on whether an encounter is matchable could be built into the system to grey out the “Match” button if it is not matchable in that particular Wildbook? That would prevent the endlessly spinning Match Kickoff page that cannot go anywhere.

Regards

Paul

Just want to report back something from @colin that came up while discussing these issues:

When we first developed this, those were prevented. He remembers much frustration with getting it to work correctly, so I trust this.
We are having a couple of issues around things not having gotten down various branches correctly, hopefully this is one of those things.

WB-1519 now has a fix deployed. It’s in review but the filtering should be restored.