Ability to select multiple instrument sessions should be considered

[EmsArnold]

For the majority of use cases, users will want to have one and only one session selected. A small subset of use cases (beamline scientists setting up UDC) will want to select multiple sessions for interaction with ULIMS.

Where this "multiple session selection" is available should be considered, as having it attached to the global instrument session selection is likely to be confusing to users.

[zoharma]

@EmsArnold It should only apply to users with that capability, not to everyone. So not sure why would it be confusing?

[EmsArnold]

It should only apply to users with that capability, not to everyone. So not sure why would it be confusing?

1. Currently I don't believe there is a way to tell the difference between staff and users, so there is a technical issue here.
2. Staff will also want to interact with the beamline outside of the queue, and having the UI arbitrarily choose which session is used for these interactions is not ideal

Each component which takes an instrument session would have to deal with this (and preferably throw an error) if more than one session is selected. In the case where there is only one page which needs multiple sessions, but currently multiple which require only one, this is then confusing as to why you are able to select multiple sessions for interaction with blueAPI

[zoharma]

@EmsArnold I thought that this solution might be useful for analysis workflows, but maybe I'm wrong, and the single session selector would be sufficient.

We could apply the global selector in a different way on the table it self as a "filter" override.

[EmsArnold]

@zoharma , there is a slim chance that users will have multiple sessions (with the current limitation of being within to 40 day time limit before data is archived) which they will want to run the same workflows on. I've only known a few user groups which have had multiple sessions on the same instrument within the 40 days. Most of the time, these sessions are not the same experiment and would require subtly or drastically different processing pipelines.

I may also be wrong, and if it becomes a lot easier to retrieve data from the archive in the future, I think this would be very useful for analysis, though still not very useful for DAQ. Perhaps this is a separate component (or a choice whether to see this or not).

I also tend to use more "experimental" beamlines, which lend themselves to needing tailored processing, rather than a beamline which is more static (i.e. detectors don't tend to move, calibrations don't really change, etc.). It may be that the ability to select multiple sessions on those beamlines is very useful for DAQ.