Aria integration ideas - salk31/ScienceFacilityUserAdminSoftware GitHub Wiki
Spec questions
Current style, user driven, acceptable?
User office indicates not acceptable
How can/should authorise person linking?
Option A: ORCID id
Option B: email addresses
Do we allow un-linking at any point?
Once authorised, are external IDs stored? If stored, linked to what? User/proposals?
DLS side (possible other facilities) multiple rows might have same orcid? Same person but multiple accounts for data security reasons.
Are these accounts linked (ie. one user id)? Or are they fully separate accounts? We can't do this in ORCID currently but I think I just need to fix this.
Does Aria need all users to login? For some just need the numbers?
By login, do you mean register? Not sure I follow this (SH: I mean register and then login to do something. Was wondering if a user just comes on a visit maybe you just need the head count for your reports?)
How are/should relevant proposals in UAS be identified?
Good question - present Instruct funding option to user based on user's country and instrument's selected? (Exact restrictions to be discussed more widely). (SH: I was thinking it could probably just do access routes, DLS responsibility to identify proposals that have the wrong access route)
Scenarios?
Proposal (ready) in Aria but not in Facility
Proposal update in Aria
Proposal update in Facility
Q. What elements will we allow to be updated? We might want to restrict some behaviour. (SH: investigators? abstract? science case (PDF))
Conflicting update in both
New relevant proposal in facility
New proposals in both but not linked
Q. Situation requires further thought. When would linking not happen? If user hasn't selected Diamond in ARIA or Instruct in Diamond (SH: Some user puts a proposal into both system but doesn't link them? Choose wrong access route in UAS and doesn't get option to link... to existing aria proposal. I think this should be rare with decent system)
Architecture
A – Aria Master, UAS slave, non-Aria specific API
PRO – Least work for facilities
CON – More work for Aria writing Adapters (Facilities could pay?)
CON – Polling only from Aria could be less efficient if want low latencies
B – Aria Master, UAS slave, Aria specific API
CON – Have to harmonise APIs across all facilities
CON – More work for facilities -> slower?
PRO – Could/should be clearer what a facility would need to provide?
CON – Less flexible as a new API to rule them all? Harder to expose facility specific quirks.
CON - Illusion that would be identical, bound to be quirks.
C – P2P, non-Aria specific API
CON – Need to get authentication working two ways
CON – Harder to debug
CON – lot of work for the facility
PRO – Efficient low latency
CON - No single system can now all problems
D – P2P, Aria specific API
CON – Need to get authentication working two ways
CON – Harder to debug
CON – Really lot of work for the facility
PRO – Efficient low latency
CON - No single system can report on what is stuck
E - Facility master, Aria slave
CON - Single API
PRO - Gives facilities more control of how/when/what is synced
CON - Need N implementations?
Linking (users, proposals?)
A - Sync system(s) refuses and nags object owner to do needed work e.g. register in other system with orcid id
B - Pull into staging area (which side(s)?) and resolve locally.
Feedback
A - Facility provides the sub set, super set (needed by Aria) completed in Aria?
PRO - Only needs to be implemented once
CON - User asked to fill out to forms
CON - With feed from facility would need to sync if changes?
B - Super set on facility
CON - All facilities need to implement the same question * N (Aria still need to implement so N+1?)
Reporting
Additional API if A
Proposal list include "external id"
Person search/get by orcid id
Proposal create, with investigators
List sessions, by proposal?
Get session, including start/end, delivered shifts, particpents?
Send back feedback, part of session or own entity?