take advantage of the ezidclient for multi-threaded/asynchronous DOI registration. This will be most useful for doing large batch updates and not so much for the one-at-a-time publish actions but works in either context. https://projects.ecoinformatics.org/ecoinfo/issues/6440
use a member instance of ezid service that only logs in every 24 hours (or other time TBD) instead of every time there is an interaction with the service. Saves us many calls when doing batch updates to ezid but keeps us from trying to use expired sessions. Motivated by https://projects.ecoinformatics.org/ecoinfo/issues/6440
prevent js scriptlets from running when we return error messages to the client by escaping any potentially harmful xml blocks. https://projects.ecoinformatics.org/ecoinfo/issues/6224
allow updates to all doi: prefixes - realized we are already restricting to specific replica servers when updating these. worst case is we try to update a registration for which we are not the owner. https://projects.ecoinformatics.org/ecoinfo/issues/6440
show the SM and ORE generation buttons even if they have not registered/configured dataone. many potential MNs want to see their generated SM before registering (and we want them to too!).
restrict DOI updates to DOIs that match our server shoulder -- may consider opening this up to any "doi:" prefix if this is too restrictive. https://projects.ecoinformatics.org/ecoinfo/issues/6440
use separate surName and givenNames to lookup ORCIDs.
all full-text queries for ORCID, but it isn't that great because we might have a"PISCO" creator that shows us in may different orcid profiles...false matches.
use HttpClient to query orcid so I can easily set headers and such -- getting 503s from their production server when I test on dev.nceas...odd
adjust tests for production service -- more "real" information shows additional return values from the query.
View revisions
Also available in: Atom