You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Creating this as a tracker for what the acquisition web client might want to pull from a facility API. These are just initial ideas that could use more input from @stuartcampbell and @JunAishima. Initial ideas:
Obtain a data_session_id from the facility API for the current set of runs
Obtain related data to the session such as the proposal_id, saf_id, etc
Obtain and display useful beamline information in the interface such as name, location, contact details for relevant staff, emergency phone/email in case of issues, current status of ?
Ideally some of these things would be obtainable in prototype API that might be hardwired, along with the link to get it, i.e. the queueserver would certainly know a beamline identifier such as its FXI, HXN, etc, that would then be used to call facility API to get more information to display about the active beamline. The beamline and user identifiers might be enough to get the proposal identifier, etc.
The text was updated successfully, but these errors were encountered:
I just picked two beamline names I knew, I guess one we should use id MAD, our pod-based made up beamline. The data_session_id is what we agreed to as a string that is a unique identifier that all light sources use to uniquely identify a data collection session, it doesn't need to be here yet, but it was a proposal along with other facility specific identifiers.
Creating this as a tracker for what the acquisition web client might want to pull from a facility API. These are just initial ideas that could use more input from @stuartcampbell and @JunAishima. Initial ideas:
data_session_id
from the facility API for the current set of runsproposal_id
,saf_id
, etcIdeally some of these things would be obtainable in prototype API that might be hardwired, along with the link to get it, i.e. the queueserver would certainly know a beamline identifier such as its FXI, HXN, etc, that would then be used to call facility API to get more information to display about the active beamline. The beamline and user identifiers might be enough to get the proposal identifier, etc.
The text was updated successfully, but these errors were encountered: