Open briri opened 1 month ago
Create the table and see file first. We can update the harvester that runs each month later on as a separate ticket.
The affiliations
Table content is broken into 2 sections below. The first section should NOT be updatable if the provenance system is not the DMPTool. Users should manage that data in ROR directly.
id Int!
createdById Int (can be done by the harvester system, so this can be null!)
created String!
modifiedById Int (can be done by the harvester system, so this can be null!)
modified String!
uri String! (the unique URL that identifies the affiliation: the ROR id, or a local DMPTool URL) (FKey to User.affiliationId
and Template.ownerId
) (must be unique)
provenance String! (the system that created the record)
name String!
funderId String (the crossref funder id)
homepage String!
language String
types String[] (options are: Archive, Company, Education, Facility, Government, Healthcare, Nonprofit, Other)
acronynms String[]
aliases String[]
countryCode String (e.g. AU, US, etc.)
managed Boolean! (default to false, determines if they have ability to access as an Admin)
logoUri String (location of the logo)
logoName String (name of the file)
contactName String
contactEmail String
menuLinks String (JSON stored as [{ "link": "http://dmptool.org", "text": "DMPTool" }]
)
ssoEntityId String
emailDomains String[] (default to domain of the homepage)
feedbackEnabled Boolean (default false)
feedbackMessage Text (see current tool for default)
feedbackEmails String[] (emails that should be notified when user asks for feedback)
The current DynamoDB based affiliation search we put in place until OpenSearch is up and running isn't going to work.
To fix this, we should build a local table in the MySQL DB to house a subset of the full ROR list so that we can have something functional for testing.
My recommendation would be to just create the table and a seed file. Then update the affiliation resolvers to connect to the table instead of the DMPHub API.