Filtering during matching not working

In which Wildbook did the issue occur? Flukebook

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

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

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

What happened? Matches from bulk imports not filtered to specified region or to my data when option selected

What did you expect to happen? Potential matches to be filtered to those in specified region / datasets

What are some steps we could take to reproduce the issue? View bulk import task
13db1dc3-720f-4741-81b6-8b9bd684ae9e (2021-04-19)
and re-run a match on an encounter with filters in place

If this is a bulk import report, send the spreadsheet to with the email subject line matching your bug report

Hi @DJohnston,

I have filed this as WB-1626 and will dig deeper. Based on our separate email conversation, this looks like it is happening only when kicking off a manual match that is filtered to “My Data”. Is that correct?

Hi @jason ,

It originally happened when sending a bulk import to detection then matching.

Upon running manual matches for each encounter again, and filtering to my data, it matches against all users. When my data is not selected however, it seems to match only to my data (including data held by my collaborator - which is useful!). Essentially it seems to be doing the opposite of what it should


There is a fix deployed for this behavior that is now live on Flukebook. When selecting ‘My Data’ for determining a matching set we will now check against the submitterID for an encounter instead of the submitter list. If the submitter list did not contain your username, even if you had ownership of an encounter it could return zero results for a matching set. Discrepancies here could have produced an artificially small or empty list of matching candidates.

The identification system does a fallback comparison if provided no candidates where it compares against everything of the appropriate species and viewpoint in the system. This is why the results were large and not limited by location or user.

The internal issue ticket closed by this is WB-1626.