Add integrations proposal#25
Conversation
|
Your Render PR Server URL is https://pubpub-core-v7-prod-pr-25.onrender.com. Follow its progress at https://dashboard.render.com/web/srv-cj9k3d1itvpc73bk0rpg. |
|
| - If the creator is a community member, we use the community's name (e.g. "arcadia/title") | ||
| - These aliases are a JSON column in the integrations table that maps the aliases to IDs in the PubFields table and takes the form {"namespace/name": "Field id"}, where "name" is the editable alias that the integration developer uses to refer to that field. | ||
|
|
||
| ### Developer portal (integrations admin page) |
There was a problem hiding this comment.
would this be an additional core page for a member to configure their integration
| - Clients using the /pubs endpoint (read and write) will reference fields by slugs, not ids. These slugs are aliases controlled by the developer of the integration. When an integration (not an instance) is created, PubPub generates and stores a default set of aliases for that integration, which can then be modified by the integration developer in the developer portal. | ||
| - Since field slugs must be globally unique, they will be namespaced according to the field creator | ||
| - If the creator is an integration dev, we use the integration's name (e.g. "datacite/doi") | ||
| - If the creator is a community member, we use the community's name (e.g. "arcadia/title") | ||
| - These aliases are a JSON column in the integrations table that maps the aliases to IDs in the PubFields table and takes the form {"namespace/name": "Field id"}, where "name" is the editable alias that the integration developer uses to refer to that field. |
There was a problem hiding this comment.
if an integration author acts on behalf of a community with at least enough permissions to create new fields why would we actually care to namespace the field to a creator aside from tracking whether an integration or user edited a field. Why would we want to prevent that discrepancy.
| - Integration manifests are created in the developer portal, then downloaded. These manifests will contain the field names map and the requested permissions and be used by the API client SDK to provide type hints. | ||
|
|
||
| ### PubPub field creation | ||
| - Fields are initially registered not in the manifest, but in the PubPub core UI |
There was a problem hiding this comment.
all aboard for something like this. does this mean a pubType? is there a difference between the editable fields and a pubType. bc if users are creating pubTypes and those fields are what a member or integration can access then wouldn't this be an extension of that process.i think what im saying is would this be features added to the pubType dashboard
| #### What happens when the creator of a field updates its default slug or default display name? | ||
| Existing integrations continue to refer to that field by its old name, or whatever custom alias they had defined. Newly created integrations will use the new name by default. | ||
|
|
||
| #### What happens when an integration developer updates their alias map? | ||
| Changing the name of a field already in use could cause an integration to break, so it must be done carefully alongside updating the integration's code. To make this possible without downtime, the developer portal should have a button to "Deprecate" a field alias which would prompt the user to enter the new alias. PubPub would add an entry to the alias map from the new alias to that field ID, but wouldn't remove the old entry yet. Now PubPub will accept put requests that refer to the field by either alias, and read requests will include the same value duplicated with both aliases. The developer can then update the integration's code to use the new alias. Once the new version of the integration is deployed, they can return to the developer portal and complete the deprecation, which will delete the old entry from their alias map. |
There was a problem hiding this comment.
oh yeah updating the name of a field was one reason for namespacing...
why are these not the same problem? are we just making sure the producer of each set of fields have no collisions? i guess it makes sense to namespace them then.
by slug do you mean name? like the field name?
2 participants
Resolves #15
Adds my proposal for how integrations will work (and a small accompanying schema change).