search

kids-first / kf-persona

kids-first persona implementation
Apache License 2.0
0 stars 0 forks source link

Member page: Store user preference for private profile #25

Closed aalex closed 4 years ago

aalex commented 5 years ago

As a user, i want to allow or disallow the appearance of my profile in the searches that other users might do on the portal.

(part of https://github.com/kids-first/kf-portal-ui/issues/1247)

We need to implement the backend storage for that preference item.

Acceptance criteria

Technical details

aalex commented 5 years ago

Persona is in NodeJS and MongoDB and is pretty straighforward. Its API accepts graphQL for the queries.

nyanofthemoon commented 5 years ago

https://portal.kidsfirstdrc.org/user/2b0747ab-216e-439c-ac2e-fb92f984b8aa#aboutMe Insert you favorite hash in the url...

Velythyl commented 5 years ago

Okay so! Some info on the state of things:

  1. Currently, no matter the URL, as soon as it's of the form "/user/", it leads to the connected user's profile. We also notice that when we access the profile page, the initial URL contains our Ego token.
  2. The query that graphql does to find your profile is query {self {${DEFAULT_FIELDS}}}. Notice that this does not include any parameter querying for your own ID or anything of the sort: something on the server (Persona) takes your bearer token, decodes it, and infers what "self" is from it.
  3. I found out that there's another queryable field named "user". That field requires an ID in its query name, like so: query { user(_id: "5cfac538dff2b3001ab8c436") { /* some stuff to ask about */ } }. However, this query fails with image
  4. This means that, while the query exists, it is currently only accessible by admins.

And here's how I would propose we implement this:

a. Related to point 1, change the URL to now use the _id used by Persona (I think it's a mongo ID?). Now, when we click to see our profile, the URL contains the _id of our profile. b. Related to point 2 and 3, change the logic to now use query{self iff the _id that's in the URL is the same as the one of the logged in user. Otherwise, use query{user(_id: THE ID IN THE URL. This will make it so the permissions are easier to implement: there's no need to query the permissions when you're asking about your own profile. c. Related to point 4, make it so the query is only blocked if the user identified by the query's _id has asked not to be publicly shared. One notices that some work has already been done in the user page: if the viewed profile's ID is not the same as the logged in user, the edit fields disappear. This means that the only necessary changes for a working prototype are the ones mentioned above.

aalex commented 5 years ago

This sounds good to me. One thing I would add is that there will be two differrent pages with two different URL:

Having two different queries, in this case, totally makes sense.

aalex commented 5 years ago

(QA) LGTM