Restrict RHS compound set visibility by target AND target access string

[mwinokan]

E.g. currently in staging there are two versions of A71EV2A, and one under lb32627-66 and the other under lb32627-71.

I uploaded a RHS dataset to lb32627-66 but it also shows up under lb32627-71:

@matej-vavrek can you please check that the f/e requests only the compound sets with the correct target name AND target access string/proposal?

[matej-vavrek]

@mwinokan, it seems that we are fetching target via api/targets/?title=A71EV2A . @kaliif but I see in API filter options only title so adding access string like for example api/targets/?title=A71EV2A&target_access_string=lb18145-1 probably will not have any effect or?

[kaliif]

@matej-vavrek adding TAS to filter fields is not a problem, but even without it, the backend should not return data from other proposals. This is possibly more a backend issue than a frontend.

[kaliif]

Looking at this issue a bit more closely, @matej-vavrek why do you need to look up target here? api/compound-sets/ endpoint allows you to filter by target ID, if you have that available, you can fetch the correct compound set. @mwinokan if you can confirm that you are a member in both proposals and there's no data leak, I think that would solve the problem.

I can of course add additional fields to filters if that makes anyone's life more comfortable.

[kaliif]

When debugging this, something I observed when uploading the same compound set to multiple targets - if the set name was the same, no new compound set was created but later uploads overwrote earlier ones. That's because the compound set's name is at the moment unique and used as the primary key in the database. @mwinokan can you confirm that now that targets can exist under multiple proposals, this is not the correct behaviour anymore and the same compound set can be uploaded to different targets creating separate compound sets? Or have I misunderstood this?

[mwinokan]

Thanks @kaliif, indeed the same target name under different proposals should be treated as a separate project with its own compound sets, etc.

I noticed that the same kind of issue exists with SiteObservationTags, but I concluded that this was actually a useful behaviour

[matej-vavrek]

Looking at this issue a bit more closely, @matej-vavrek why do you need to look up target here? api/compound-sets/ endpoint allows you to filter by target ID, if you have that available, you can fetch the correct compound set. @mwinokan if you can confirm that you are a member in both proposals and there's no data leak, I think that would solve the problem.

I can of course add additional fields to filters if that makes anyone's life more comfortable.

I am not sure if I understand correctly @kaliif. When some target is chosen from the target list at the main page we get that target and then it loads the other data.

Edit: we are fetching from api/compound-sets/ by target ID https://fragalysis-matej-default.xchem-dev.diamond.ac.uk/api/compound-sets/?target=1

[mwinokan]

Included in b/e PR687

[mwinokan]

Moving back to in progress because RHS compound sets are visible across the same target under different proposals in staging

[mwinokan]

Both the 66 and 71 versions are using target=35 to fetch from api/compound-sets/ so the compound sets are the same

@boriskovar-m2ms says there might an issue with the Target landing page and both the 66 and 71 versions of A71EV2A in the target table link to the same pk=35.

@matej-vavrek please see if this is the case and resolve it

(@kaliif points out that matej's original comment hinting at this has been resolved)

[matej-vavrek]

@mwinokan, I have updated my stack. It should use target name and access string to get a target now, e.g. https://fragalysis-matej-default.xchem-dev.diamond.ac.uk/api/targets/?title=A71EV2A&project=2