Fix squonk access control (FE)

[phraenquex]

No description provided.

[boriskovar-m2ms]

Related to #937

In the F/E landing page, column header should be "visit" (target_access_string in the project record we get from /api/project), and make it a deployment variable, so that different deployments (i.e. not Diamond) can reconfigure this as required, to correspond to whatever authentication mechanism they have.

Show only target-target_access_string tuples for for the user is authorised.
ALSO show if they are public projects.

@alanbchristie from the low level design it's not clear how to get information that given target is associated with given visit nor if the project is public or private.

File Transfers and Job Requests will require a “access” identity (an integer that’s simply the Fragalysis Project record ID) and a “session_project” identity (an integer that’s simply the Fragalysis SessionProject record ID)

Hover over "Project" (sessionproject:target_access_string displayed in the header next to the target in the header of the preview page) should ideally pop up that cute dropdown in #1010 (requires having #1010 implemented).

[alanbchristie]

Public/Private

I'm not sure how the backend determines this either. It uses ISPyB to get a list of "visits"/"target access strings" (TAS for short) for a given user. What's obtained is simply a list of strings. The B/E then filters Project (Proposal) records based on the that list. The Project (Proposal) has fields for TAS and init_date

Target/Project correlation

The existing /api/targets endpoint contains a list of Project IDs in its response (project_id). If the user has access to the corresponding project it should be in the /api/projects response. (I have updated the LLD to add this clarification)

[boriskovar-m2ms]

Oh yes you're right. I completely forgot about this. Brain still restarting after two weeks.

[boriskovar-m2ms]

@alanbchristie @phraenquex

Public/Private

according to this:

Yes, show only target-target_access_string tuples for for the user is authorised.
ALSO show if they are public projects.
For that: introduce a column "open_to_public", which is boolean, if TRUE, pass that to front-end, so it can annotate the projects.

For current targets: provide a list of targets (and dates if available) - stick in this ticket - and we (Frank, Daren) will flush out the target_access_string from ISpyB.

the info whether the project is public or private is not part of the information we get from ISPyB and this will be information stored only in backend with some UI to set this value?

Or if target_access_string is set to OPEN then it means that it's open?

Or better project which is closed will be returned with list of user_ids which are authorized to access the project? How can I actually create additional test projects? Because now it seems that I have only one and most likely open project.

[phraenquex]

The open_to_public field must be set one-by-one. For now it will be by an admin - the UI will come later, the spec is somewhat non-trivial (for legal reasons).

"target_access_string" is unfortunately currently the place where it's labelled "OPEN", but that's a very very bad design mistake from the heat of 2020 pandemic. So it's urgent that it be fixed.

I assume you're coordinating directly with @alanbchristie (Slack or similar).

[alanbchristie]

With regard to Public/Provate the current set of Project records on the production site is as follows,
in the form <id>|<proposal/title>|<init_date>: -

1|private_dummy_project|2019-04-02 09:02:27.951796 +00:00
2|OPEN|2019-04-10 09:40:03.881378 +00:00
3|19400|2019-04-10 15:58:13.780068 +00:00
4|19400-1|2019-04-10 15:58:13.806151 +00:00
5|13385|2019-04-10 16:01:10.512515 +00:00
6|13385-87|2019-04-10 16:01:10.533086 +00:00
7|20179|2019-04-10 16:01:11.280015 +00:00
8|20179-1|2019-04-10 16:01:11.302760 +00:00
9|20289|2019-04-10 16:02:32.496304 +00:00
10|20289-1|2019-04-10 16:02:32.519416 +00:00
11|19990|2019-04-10 16:05:18.851857 +00:00
12|19990-1|2019-04-10 16:05:18.939255 +00:00
13|18145|2019-04-10 16:07:58.914098 +00:00
14|18145-44|2019-04-10 16:07:58.941297 +00:00
15|16974|2019-04-10 16:09:40.610729 +00:00
16|16974-1|2019-04-10 16:09:40.631740 +00:00
17|16949|2019-04-10 16:13:08.913539 +00:00
18|16949-4|2019-04-10 16:13:08.934918 +00:00
19|16949-12|2019-04-10 16:13:09.813017 +00:00
20|19572|2019-04-10 16:14:17.683007 +00:00
21|19572-1|2019-04-10 16:14:17.701865 +00:00
22|18944|2019-04-17 16:01:40.710275 +00:00
23|18944-1|2019-04-17 16:01:40.735978 +00:00
24|18954|2019-10-25 13:11:03.747988 +00:00
25|18954-1|2019-10-25 13:11:03.772062 +00:00
26|27001|2020-06-30 11:59:49.330344 +00:00
27|27001-2|2020-06-30 11:59:49.410035 +00:00
28|22717|2021-02-19 13:53:10.551660 +00:00
29|lb22722|2021-10-04 12:03:26.353396 +00:00
30|22722|2021-10-06 16:19:47.062029 +00:00
31|lb27156|2021-11-12 13:30:01.739906 +00:00
32|27156|2021-11-15 13:23:12.738109 +00:00

[phraenquex]

For direct-access URLs:

• For open projects, allow there to be no target-access-string
  • then search through the open projects, and if there is more than one with that targetID, present user with a choice (modal?) - show datestamp.
• For closed projects, MUST have target-access-string
  • If no-one logged in, then first get person to log in
  • then check if that logged-in person has access
  • (Don't worry about historic snapshots for non-open projects. That's their problem, it was always Alpha.)

Path for target may as well fully qualify the target-access-string, e.g.
https://fragalysis-tibor-default.xchem-dev.diamond.ac.uk/viewer/react/preview/tas/lb20133-5/target/ATAD2A/

Behaviour if access revoked to "session-project":

• Show a modal, saying:
  • "You don't have access to project; please contact the proposal PI or Alternative Contact. If you previously had access, likely your access was revoked - your PI/AC can resolve this."
• String should be configuratble for the deployment/stack - this one is Diamond-specific.

[phraenquex]

To generate a closed project for Boris to test:

• Daren assigns Boris to any old visit (that he is entitled to)
• use the visit id of something that Fragalysis has not yet seen
• upload anything - keep it small (Warren)
• send the data to Boris too (Warren)

Tell Boris the target/TAS.

[phraenquex]

For this release, just add a very simple bit of text to the Error modal that tells you you can't access target/target_access_string.

"If this is unexpected, do retry your action, as there is an ongoing sporadic mis-authentication (being debugged)."

@boriskovar-m2ms I assume this is a trivial fix - please confirm/comment.