Facilities

[TCMeldrum]

Over time at the STFC there have been some requests for features that could be solved with the concept of a facility, a few examples are:

• Instrument Scientists who are not on any instrument on the Call still need access to the proposals  issue-tracker#1238
• A "facility user officer" who has user officer powers over a sub set of proposals/calls/templates
• Investigate how instrument scientist might see other proposals not assigned to there instrument issue-tracker#877

Some we have found workarounds for, but it seems to come up in as a request repeatedly. To solve issue #1238 we could implement a workaround or start work on a facilities' implementation.

What would a facility implementation looks like?
As a first pass, this is what I propose, something like this:

We would then have a new user role, something like "proposal reader" that would be able to see all proposals that are transitively through there instrument connected to there facility.

We could then extend this later to have a concept of a "facility user officer" that can manage stuff that is related to their facility.

What do we think?

[jekabs-karklins]

Hi Thomas,

I hope you’re doing well! I wanted to clarify a few quick points to better understand the use case:

• Regarding information sharing - Is there any data or processes that need to be shared between facilities, or are they fully independent?
• Regarding User office operations - Can the two facilities run separate instances of the user office, or is coordination required?

These aren’t suggestions - just questions to help me grasp the setup more clearly. Thanks in advance!

[TCMeldrum]

Thanks for the reply!

• For information sharing, I don't think so, they should be fully independent.
• As for running 2 instances of the user office, we have considered this, but don't want to have to do this. We had a situation like this in our old proposal system where we did run a separate system for the different facilities, and it ended up being a mess I think. Maybe @ACLay @srconway could expand on this?

[ACLay]

Our old "system" was actually more like 4 different instances that were potentially originally forks, but diverged so far over the years that they were essentially entirely unique with no interoperability. We had a main ISIS instance, a main CLF instance, one for ISIS Xpress and one for ISIS Callibration and Commisisoning. It was a mess, as was the proposal lookup API we had to try and act as a single queryable datasource for all of them. I have no desire to go back to multiple systems that we'd then need to try and somehow combine.

[srconway]

Yes, as Alex says I think we want to avoid needing to run separate instances if we can - the downstream systems for scheduling and visit management support multiple facilities so it could quickly get messy if we have multiple submissions systems feeding them, even if we're confident we can keep the core software in sync (unlike our legacy system).

Presumably we could in principle make new roles that tie to instruments, so someone would be a feasibility reviewer for multiple instruments, but given that we have 30+ instruments in one facility this could quickly become unmanageable. Any change to add or remove someone from a "facility" role would require repeating the operation on all instruments within that facility, again not something we want to do (or not manually anyway)

[bolmsten]

Hi Thomas,

I recently spoke with @CarinaLobley and she informed me that she, Emma and Zita had created a list of all roles that they saw needed in the software. I am wondering if you have talked with Emma on this as it seems you are adding more roles here.

[TCMeldrum]

Emma seemed to be on board with it, although maybe we could use the instrument sci roles instead.

[CarinaLobley]

Ah ... we didn't talk much about the idea of more than one facility. BUT I think this is a conversation Zita would be interested in for ELI as well as STF for ISIS and CLF ...

Let me add more detail to confuse everyone! We talked about possible new roles and the one I think is relevant here is that rather than having 'internal reviewers' who are a bunch of people who can be invited to do something by the instrument scientist, we would have 'feasibility reviewers' who could see all the proposals submitted and could edit the feasibility as they chose. BUT these would need to be ISIS people seeing ISIS proposals or CLF people seeing CLF proposals and not ISIS people seeing CLF proposals.

Currently I think instrument scientist is the only role where views are limited by instrument (and thus facility) and so this role is being used in all situations.

Maybe that helps ... 'feasibility reviewer' is my own invention and this may not be the right term!!!

[TCMeldrum]

There doesn't seem to be any major objections (tho it is not too late, if anyone has any suggestions please add them) so I am going to ahead and implement facilities with the structure I described above.

I think it would be easy to expand to a feasibility reviewer role if and when it is needed.

[jekabs-karklins]

Hi, @TCMeldrum,

So as I understand, multiple facilities feature would enable you to define new roles, or refine existing roles with more fine-grained permissions, by either locking access within the facility (reducing the noise) or enabling cross facility access (like in UserOfficeProject/issue-tracker#1238).

Is it fair to assume that after implementing this feature for ESS, we would default to just one facility, as this is not really relevant to us in the current state?

[TCMeldrum]

Yeah, I think I would be on the side of defining new roles, currently look at some kind facility-proposal-reader and a facility based user officer. I think currently for ess and anyone who does not want multiple facilities we could hide it behind a feature flag.