Include an explicit indicator for SGID group/Open Data sharing in the meta table(s)

[jacobdadams]

Sharing an item with SGID Open Data is currently a by-product of sharing it with an SGID group in AGOL. Auditor currently changes the group based on the fully-qualified table name in the meta table. Thus, getting Auditor to remove a dataset from Open Data would require either not processing that row (by changing the itemid field in the metatable) or shelving the dataset. Auditor would also overwrite any manual attempt to unshare the item from the SGID group.

There are two potential solutions to decouple this, and a combination of both may be desirable:

1. Explicitly define the AGOL group in the metatable. This involves a duplication of information (group is encoded in both the table name and the new field) and could lead to out-of-sync issues between the database group and the AGOL group, but it gives us more fine-grained control over the AGOL Group.
2. Create a single "Open Data" group to control Open Data sharing and remove the "Share with Open Data" from the SGID AGOL groups. This may require changing how our Open Data landing page icons work (I think they're currently based on groups), but I need to dig into this more.
   • Also, this could change how external orgs share their data with our open data groups. Maybe we need two groups per category, an SGID group and an SGID Open Data Group? So SGID Cadastre and SGID Open Data Cadastre?

[jacobdadams]

Pinging @gregbunce. I'll bring this up in our next Data Team meeting.

[jacobdadams]

Current Situation
SGID Groups

• Used to share items with SGID Open Data (groups are "enabled for open data")
• Roughly match SGID Categories
• Used for cards on opendata.gis.utah.gov (each card links to a search query using the group ID)
• Used as an access point for external agencies to share data with SGID Open Data
• Not available in current Open Data search UI (but the custom URL query by group ID works)
• Segments data within ArcGIS Online

[jacobdadams]

Potential Solution—Categories

• Groups appear to be meant to be used for sharing and access control, not content categorization within an organization.
• Categories could be used instead of Groups
  • Categories could be created to mirror our SGID categories
  • Categories show up in the open data search UI
  • The landing page cards can be switched from groups to categories
  • AGOL items can be assigned more than one category
• Remove all the SGID Groups
• We'd still need at least one group that controls whether an AGOL item is visible in open data
• Not sure yet how Categories would work with data coming from external orgs- they may need to have the appropriate category in their org? Or maybe they just wouldn't show up in any category (which could be bad)
• Extend metatable with an "SGID Open Data" field to capture whether it should be shared in SGID Open Data or not
• Auditor shares items with the one SGID Open Data group based on this field.

[jacobdadams]

Potential Solution—Use Existing Groups only for Open Data Sharing

• Stop using SGID groups for AGOL segmentation and only use for open data access and segmentation
• Requires very little change to open data site
• Allows sharing from other orgs under current scheme
• Only share items with the groups if they should be in SGID Open Data
• Extend metatable with an "SGID Open Data" field to capture whether it should be shared in SGID Open Data or not
• Auditor shares items with appropriate groups based on fully-qualified table name.