You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need a more robust strategy for determining a unique name for sites/assets.
The current strategy for determining a unique ID for a site assumes a subdomain containing place-related information.
But not all CivicPlus sites have a place-oriented subdomain. For example, Napa County has a broken CivicPlus subdomain but a working AgendaCenter site on its own county domain (as of late Dec. 2020):
# Broken
https://napa-county.civicplus.com/AgendaCenter
# Working
https://www.countyofnapa.org/AgendaCenter
With the current strategy, we end up producing asset names such as below:
civicplus_www_12072020-1666_agenda.pdf
The text was updated successfully, but these errors were encountered:
It would be possible to add some logic that could devise a unique name for an asset other than its subdomain on CivicPlus. For example, given a non-standard URL such as Napa County (https://www.countyofnapa.org/AgendaCenter), we could derive the name from the base domain. However, this would pose downstream issues in code that expects the state_or_province and place data to be present. These data points are derived currently from subdomains.
Two possible strategies that would be more robust:
Use the subdomain generally and for edge cases look up the state and place data in a corrections dictionary.
Rely on a canonical list of known domains and their verified geographic information.
We've already started down the path of manually correcting state/place data in aw-scripts because there are problems ascertaining this info even on subdomains, such as for water districts. Will likely need to use some form of the "corrections" approach here in the core framework to generate accurate, standardized place information for each site.
We need a more robust strategy for determining a unique name for sites/assets.
The current strategy for determining a unique ID for a site assumes a subdomain containing place-related information.
But not all CivicPlus sites have a place-oriented subdomain. For example, Napa County has a broken CivicPlus subdomain but a working AgendaCenter site on its own county domain (as of late Dec. 2020):
With the current strategy, we end up producing asset names such as below:
The text was updated successfully, but these errors were encountered: