summaryrefslogtreecommitdiff
path: root/issues/authorisation.gmi
blob: 0adac56b7ee31360ea734c51328fc221ef5249bb (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
# Clean up Authorisation

Look at Chris' authorisation code:

=> https://github.com/genenetwork/gn-proxy

Atm genenetwork2's handling of
authorisation is a bit clunky; Since @Bonface is working on the data
data up-loader, and it requires authorisation, this is a good time to
clean up authorisation.

# Tags

* assigned: bonfacem, pjotrp, zachs

# TODO

- [x] Make user able to delete/ add extra value

- [x] Fetch complete list of samples from database and genotype file
  instead of only fetching that list from the database.  Look at trait
  page for reference.

- [ ] Extend idea of csv generation to probeset data.  Get data from
  the genotype file and work out how to update the values from the
  database.

# Notes

mRNA datasets ("ProbeSetFreeze" in the DB) contain traits, so when you
assign privileges to an mRNA dataset, it will apply to all traits
within.

But the phenotype resources (for example the dataset name
"BXDPublish"; the stuff in the PublishXRef, etc tables) are just the
traits themselves. The rows of "PublishFreeze" in the DB don't
correspond to individual resources like the rows of ProbeSetFreeze
(neither do databased genotypes - GenoFreeze - for that matter). There
isn't really any "containing" classification for them beyond the
group. BXD phenotype traits can each come from different studies and
thus have different privileges for different users, etc, but there's
nothing in the database really representing that.

This means that if you want to change privileges for phenotype data,
you have to do it trait by trait (or at least to a selection of traits
you manually choose). But for mRNA ("ProbeSet") traits you can just
refer to the entire dataset (and as far as I'm aware this will always
be the case; there's never a need to assign privileges trait-by-trait
for the mRNA traits.

Another way of representing this is that for mRNA datasets you have
the following levels:

Species -> Group -> Dataset (this is a resource) -> Traits

But for phenotypes/genotypes:

Species -> Group -> Traits (each is a resource)


On the UI(quote from Zach):

> One interface issue I ran into is how to add/remove groups (since
> currently the proxy only cares about groups for retrieving the
> privilege masks). I think I set it up so that you can search for
> groups by a user's name, e-mail, or parts of the Group Name itself,
> though I was uncertain about that because it means that anyone doing
> this could see every group/user.  For adding users to a group, I
> have people direct input e-mails (instead of giving the ability to
> search).

#### Mon 18 Oct 2021

- Marked the function `check_owner_or_admin` as deprecated. It's only
  used in: `wqflask/show_trait/show_trait.py`.

- Heavy use of the walrus operator to remove alot of boiler plate.

#### Tue 19 Oct 2021

- Every resource needs to have the 3 fields set for the group-mask and
  default-mask: "data", "metadata", "admin". Otherwise, a hash-ref
  error will be thrown:

```
03 ~~> hash-ref: no value found for key
  key: 'admins
```

  On this regard, the documentation for gn-proxy should be updated
  since it's abit misleading.

- An owner, from the proxy views has super-user privileges for
  everything

#### Mon 26 Oct 2021

- Some issues Zach pointed out:

> The /trait/update endpoint*, when accessed from >
  "/trait/<name>/edit/inbredset-id/<inbredset_id>", currently doesn't
  seem to work because kwargs/args are empty. This is presumably due
  to it being a POST endpoint and not having the necessary fields
  passed through the URL. I can access all the form inputs in the
  decorator with request.form, though those form inputs still don't
  include the resource_id or inbredset_id/dataset_name with those same
  variable names; they're in the edit_phenotype form as inbred-set-id
  and dataset-name respectively (this is why I mentioned the variable
  names; if I gave the decorator access to them with request.form,
  they didn't match the variable names it expected).  So I'm not
  really sure how best to fix this; I'm guessing that either the >
  trait/update endpoint needs to be changed to include the resource ID
  > (though this is complicated by the fact that there can be many
  traits within a resource_id for ProbeSet traits; it's only phenotype
  traits where each individual trait is its own resource), or the
  decorator itself needs to be changed to also access request.form.

> There's also a separate issue with
  "/trait/edit/probeset-name/<dataset_name>" that likely stems from
  the fact that you need both a dataset name and trait ID for
  "probeset" traits (and in this case dataset_name is actually the
  trait ID). So this probably calls for the endpoint itself being
  changed in some way.

- Fixed the above, while at the same time, adding the new auth links
  to the show trait page. Key point is that I changed the URLs and
  moved them to their own module. Particularly for published datasets.

- New PR: https://github.com/genenetwork/genenetwork2/pull/614