Quick note on verifying WorldMap layers

verify_wm_layers.md

Note: of these 3 points, the core question is in 3. Geoconnect uses a Dataverse API endpoint to delete any stale WorldMap layer metadata objects.

• e.g. Is this the preferred method or use other options?

---

Current Approach

1. Add Dataverse API endpoint* to retrieve WorldMap layer metadata objects

(*already checked in by @pdurbin)

• API Questions:
  • What token or user is allowed to read all of these WorldMap objects from (published) files spanning many datasets?
    • Since everything here is public, it could potentially be any user or user token
  • Should a new role be created that has permission to use this API?
  • Keep in mind that Geoconnect may potentially be reading these objects from all Registered Dataverses.
    • This adds the complexity of Geoconnect needing to have a user/token from each Registered Dataverse
    • The added work here is not technical but having registrants give some type of token from their Dataverse
      • The tech work of adding columns to the "Registered Dataverse" table is about a 15-20 minute task and well within the scope/work of this ticket

2. Geoconnect uses API results to verify that layers do exist

1. Via a scheduled task, retrieve a list of WorldMap layer objects
2. Iterate through and test that the WorldMap layerLink goes to a valid page (returns a 200)
   • Note: Distinguishes between the WorldMap server being available and the map not existing

3. Geoconnect uses a Dataverse API endpoint to delete any stale WorldMap layer metadata objects

Issue: This API faces the same questions in (1)API Questions except:

• The user/token does needs to have special delete permissions
• Option A: Using existing infrastructure, create a Dataverse "service user" that has a special "manage WorldMap metadata" role
  • Store the service user API token in Geoconnect
• Option B: Create a "special token" using the worldmap token tables (a bit hackish one-off)
• Option ?: Just added A&B to start discussion

Potential alternative? (not a good one but to start conversation):

• Keep any delete functionality within Dataverse
• Example:
  • Geoconnect doesn't delete anything but sends an email to the Dataverse administrator alerting her/him of stale WorldMap objects
  • The Dataverse administrator (with superuser permission) uses a link within the email to go to a Dataverse page that:
    • Lists the stale map metadata links with an option to delete them
    • This would keep any delete/update functionality within each Dataverse
    • This would put the decision to delete in the hands of each Dataverse installation
      • Admins will alerted about stale WorldMap objects and then can choose to delete them