Expose registry as a catalog #255
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- the `ermrest` db gets catalog treatment (_ermrest schema, history tracking, etc) - the registy logic targets the `ermrest.registry` table instead of `ermrest.simple_registry` - existing catalog/alias APIs remain as the way to manage catalog lifecycles - a self-referencing link for id `0` to the `ermrest` DB is added to the registry - the /ermrest/catalog/0 data APIs allow viewing of registry records - basic read-only policies are applied when provisioning the registry table - limited self-service write access is allowed to modify text description fields
- descriptor column may have JSON `null` value or SQL null - do not copy owner array content to RCB/RMB since values may be invalid client IDs
to protect built-in functions: 1. prevent insert/delete of registry rows via data APIs 2. prevent write to core registry columns via data APIs 3. prevent dropping of core registry columns 4. prevent dropping of core registry fkeys
This will default TRUE and not really serve a purpose in typical deployments. A site might opt to deploy an auto-expiry script to delete non-persistent catalogs after some lifetime is reached. They might also revise the column default to FALSE and/or adjust policies to decide which self-service clients can adjust the flag.
…ias APIs - name - description - is_persistent - clone_source (only for catalogs)
Along with default ACLs, apply default annotations so that the Chaise UI is sensible when looking at the ermrest:registry table.
… step in the default config, the client won't have permission to do this.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The registry is the built-in
ermrestdatabase which tracks all API-provisioned ERMrest catalogs. This feature converts the registry into a special catalog accessed at/ermrest/catalog/0. This can provide read access to enumerate catalog and alias records as well as limited write access to modify descriptive metadata.The default configuration provides a self-service policy so that the same client ID who provisioned a catalog may update its metadata. It also has default annotations to provide a basic catalog enumeration UX by visiting
/chaise/recordset/#0/ermrest:registry.Because the existing deployment strategy has not defined any overall "owner" ACL for the site operator, the owner ACL of this special catalog is initially empty. The site operator must first change this via local SQL access if they wish to enable API-based management of the registry catalog. For example, run commands like this against the
ermrestDB:There are built-in authorization restrictions so that unsafe changes are not permitted on the registry catalog regardless of how the operator customizes its policy. The existing web APIs must be used to manage the lifecycle of catalogs and aliases and these other APIs will add or remove rows from the registry table.