Wildbook 10.14: location roles now work on every page, in search and through the API

2 hours ago

Wildbook 10.14 is a small bug-fix release. Its main change is that location-based roles now work everywhere in Wildbook, instead of only on the classic pages. The rest fixes zooming on the Match Results page, matches started from a project page, and one untranslated label.

Ask about this presentation

Chapters

  1. 0:00Location roles everywhere
  2. 0:19What a location role grants
  3. 0:36Honoured everywhere
  4. 0:54Moving an encounter needs edit rights
  5. 1:11Zoom stays where you point
  6. 1:31Project-page matches finish
  7. 1:53Smaller fixes
  8. 2:13Setting up location roles
  9. 2:38Upgrading to 10.14
Show transcript
  1. Wildbook 10.14 is a small bug-fix release. Its main change is that location-based roles now work everywhere in Wildbook, instead of only on the classic pages. The rest fixes zooming on the Match Results page, matches started from a project page, and one untranslated label.

    Slide text

    Location roles now work on every page, in search and through the API

    Plus fixes for Match Results zoom and for matches started from a project page.
    Wildbook logoWildbook 10.14
  2. A location role is a role named after a location ID, such as Indonesia. Its holders can view and edit encounters at that location and anywhere below it. Access only flows downward, so a role on a child location still grants nothing on its parent.

    Slide text

    A role named after a location covers it and everything below it

    Role names match location IDs, such as Indonesia or ORP-Pakistan.
    Parent location no access from the role Location with the role role name = this location ID Child location view and edit Child location view and edit Below that view and edit
    Wildbook 10.14
    Access by location
  3. Until now, only the classic pages honoured those roles. So the same user got the start a collaboration prompt on the React encounter page, and search showed that encounter as inaccessible. In 10.14 the React pages, search and the API all honour the role.

    Slide text

    Until 10.14, only the classic pages checked location roles

    Classic pages
    React pages
    Search
    API
    Before
    ✓ Honoured
    ✕ Ignored
    Encounter page asked to “start a collaboration”
    ✕ Ignored
    Encounter listed as inaccessible
    ✕ Ignored
    10.14
    ✓ Honoured
    ✓ Honoured
    ✓ Honoured
    ✓ Honoured
    Wildbook 10.14
    Access by location
  4. The same work closes a gap. Any user with the researcher role could change the location of any encounter. Now only someone who can already edit the encounter may move it: the owner, an admin, an edit collaborator, or a location role that covers where it is now.

    Slide text

    Changing an encounter’s location now needs permission to edit it

    Before
    Any user with the researcher role could move any encounter
    10.14
    Only users who can already edit it, at its current location
    Owner Admin Edit collaborator Location role covering it
    Anyone else gets 403 access denied from EncounterSetLocationID.
    Wildbook 10.14
    Security
  5. On the Match Results page, zooming used to anchor on the image's top-left corner, so the animal slid out of frame, often by several hundred pixels at the starting magnification. Now the mouse wheel zooms around the pointer and the toolbar buttons zoom around the middle of the pane, so the animal stays in frame.

    Slide text

    On Match Results, zoom now stays where you are pointing

    Before
    Zoom anchored on the image’s top-left corner
    the animal slides away
    10.14
    Wheel zooms about the pointer, buttons about the middle
    the animal stays under the pointer
    Wildbook 10.14
    Match Results
  6. If your matching uses MiewID or another vector-based configuration, Start Match on a project page has been broken since 10.10. It threw the results away, and the page said match results are still being processed, forever. Now results are saved as each annotation finishes, so one failure no longer discards the matches that already ran.

    Slide text

    Project-page matches now finish

    The Match Results page header with a project selected
    Match Results, with a project selected
    Since 10.10.0
    “Start Match” ran the comparison, then threw the results awayThe page sat on “Match results are still being processed” forever.
    10.14
    Results are saved as each annotation finishesOne failure no longer discards the matches that already ran.
    Affects installations whose IA.json uses MiewID or another vector-based configuration.
    Wildbook 10.14
    Identification
  7. Back on Match Results, the This Encounter label over the query image now links to that encounter in a new tab. When the page shows several algorithms, each section links to its own query encounter. And in the image modal's tags panel, the existing-keyword dropdown shows its label instead of a raw translation key.

    Slide text

    “This Encounter” is now a link to the query encounter

    Match Results · query image label
    This Encounter ↗
    Opens in a new tab. With several algorithms on the page, each section links to its own query encounter.
    Image modal · tags panel
    SELECT_EXISTING_LABELLED_KEYWORDThe dropdown shows its label
    It used to show its raw translation key.
    Wildbook 10.14
    Match Results and other fixes
  8. To use location roles, an admin lists the location names as role entries in the common configuration file, and they become checkboxes on the user admin page. The five reserved names, like admin and researcher, never count as locations. Search picks up new grants on the next background permissions pass, at least every 45 minutes by default. Editing the location tree needs a restart.

    Slide text

    Admins grant only the location roles listed in the site’s config

    # commonConfiguration.properties
    role0 = admin
    role1 = researcher
    role2 = rest
    role3 = machinelearning
    role4 = orgAdmin
    Add your location names as more roleN entries. These five reserved names are never read as locations.
    They become checkboxes in appadmin/users.jsp when assigning roles
    Search catches up within 45 minutes on the next background permissions pass, by default. backgroundPermissionsMaxForceMinutes in OpenSearch.properties
    Editing locationID.json needs a restart Creating or deleting a role schedules a permissions pass by itself.
    Wildbook 10.14
    For administrators
  9. Upgrading needs no database schema change and no ml-service upgrade. Deploy the new WAR, then start any project-page matches that were already stuck again, because they won't recover on their own. After that, location roles work on every page, in search and through the API.

    Slide text
    A beluga whale in dark water

    To upgrade, deploy the new WAR and restart stuck project matches

    No database schema change
    No ml-service upgrade required
    Matches already stuck on a project page need starting again
    github.com/WildMeOrg/Wildbook/releases/tag/10.14
    Issues reported by @goddesswarship · reviewed by @naknomum
    Wildbook 10.14
    Upgrade

What happened in AI today, in your inbox

One short email each evening. Read it and you’re caught up.

Built in New York with ❤️