[User Registration] Need to Define JSON Spec for User Profile

[BethanyG]

Background

In talking through User Registration, email validation, and login flow, we realized we haven't defined a user profile or user JSON Spec. Now sounds like a good time for that.

Acceptance Criteria

[ ] Basic, working JSON Spec. for a user profile, in support of new user registration
[ ] Spec should have email as a required field (see issue #111 ) Please see discussion 178 for more details here.
[ ] Spec should include any extended info we want to track for users
[ ] Spec should not include things like related projects, resources, notes, or hangouts, which should be defined in their own endpoints.

This Issue Depends On

No dependancies as it stands (this is the JSON spec) - although we need agreement from the front-end team before we implement this as a users endpoint.

Open Questions

Assumption here is that we'd only track qualities specific to users - so while things like:

1. learning paths
2. hangouts
3. discussions
4. notes
5. resources
6. study groups
7. projects
8. tags of interest

Would potentially appear in the GUI for a Users profile, they would not be returned by a users endpoint, and would not be saved as part of a users.user table.

[BethanyG]

This is our current user (based on the users.json fixture we have in the repo):

model users.user
"user":{
            "id":39,
            "password":"password-hash-here",
            "last_login":"2020-01-07T02:32:09.518Z",
            "is_superuser":false,
            "username":"georgiag",
            "first_name":"",
            "last_name":"",
            "email":"gggreat@gmail.com",
            "is_staff":false,
            "is_active":true,
            "date_joined":"2019-08-29T07:40:59.664Z",
            "name":"",
            "groups":[

            ],
            "user_permissions":[

            ]
}`

[lpatmo]

Would potentially appear in the GUI for a Users profile, they would not be returned by a users endpoint, and would not be saved as part of a users.user table.

👍That makes sense!

We're talking about what we'd want to see on a user's profile page after a user logs in (aka a GET request to a /users/{user_GUID} API endpoint), right?

if so, I'm thinking what is acceptable for our MVP would be:

{
            "id":39,
            "username":"georgiag",
            "first_name":"",
            "last_name":"",
            "email":"gggreat@gmail.com",
}

Any additional fields that Django would give us would be great/additional icing.

In terms of our own custom fields (if we wanted to add in additional user profile fields), I'm imagining:

{
            "id":39,
            "username":"Carolyne.Carter",
            "first_name":"Carolyne",
            "last_name":"Carter",
            "email":"Carolyne.Carter@yahoo.com",
           "introduction": "I am an experienced front-end engineer",
           "skills_to_improve":"SQL, NodeJS",
           "skills_can_help_others_with": "HTML, CSS, JavaScript, React, ES6, MySQL, Jest, Express, NodeJS",
          "timezone": "GMT"
}

Open to discussing any of the above! (Also in favor of cutting it down to minimum that we need for now.)

[BethanyG]

So I don't think it would be too hard to add those final 4 fields (introduction, skills_to_improve, skills_can_help_others_with, timezone) into our model.

Although it would be "hidden" or "hashed", we will have to have the password and role/level available as part of the user/user profile also. Let me think on that.

[lpatmo]

So I don't think it would be too hard to add those final 4 fields
Cool! And, sorry -- let me introduce one more -- an image URL field (image can be hosted externally). I noticed this pattern in another startup's form just now and seemed like an easy way to get around having to support image upload and host images ourselves.

{
            "id":39,
            "username":"Carolyne.Carter",
            "first_name":"Carolyne",
            "last_name":"Carter",
            "email":"Carolyne.Carter@yahoo.com",
            "image_url_external": "https://avatars2.githubusercontent.com/u/9362535?s=200&v=4"
           "introduction": "I am an experienced front-end engineer",
           "skills_to_improve":"SQL, NodeJS",
           "skills_can_help_others_with": "HTML, CSS, JavaScript, React, ES6, MySQL, Jest, Express, NodeJS",
          "timezone": "GMT",
          "is_staff":false,
          "is_active":true,
}

I was thinking the only possibly will-take-more-time-to-implement field would be timezone, since it'll need to be a CHOICES list rather than a freeform text input.

Although it would be "hidden" or "hashed", we will have to have the password and role/level available

Do you mean that the password would need to be hashed in the DB? (We don't need it returned in the GET call, right?)

Re: role/level -- am remembering now that Django gives us is_staff = false and is_active=true for all non-admin users; makes sense to see that returned in the JSON request too to distinguish between "regular" users vs. "admin" users, so I updated my example above in this post.

[BethanyG]

Do you mean that the password would need to be hashed in the DB? (We don't need it returned in the GET call, right?)

Ooof. I don't wanna over-complicate this, and we may want to shelve it for the MVP. But my assumption would be that a user's profile would give them access to re-setting their password and/or changing their username, email, and password - or any info associated with them.

So it may not be this GET endpoint. We may have another one for when a user goes into "change" mode that requires them to auth/re-auth. And of course, if we go the route of allowing social auth, that would be a twist as well...because we may (or may not) want to allow the user to change the service they auth against/switch to an email auth account, etc.

Ok. Let's just say that we don't have the PW for this endpoint...but we need to maybe open a different issue for the whole "user wants to change their profile" scenario. 😛

I was thinking the only possibly will-take-more-time-to-implement field would be timezone, since it'll need to be a CHOICES list rather than a freeform text input.

..we could go a few directions on timezone. One would be to have it read from the browser locale and sent to the backend to save initially ... then have it show on a users profile so if they want to change it, they can. Another would be to show them the time in UTC when they are setting things up, and default the display to their local time by having a [+ x hours] or [- x hours] toggle -- so 10:30pm PDT would be 5:30am UTC [- 7 hours]. Or - we can have a CHOICES list, like we have with Resources -- but it wold be a looooong list. Django uses pytz, which supports almost all the timzones listed here. Even if we only took the "canonical" ones, it is quite ridiculous.

Either way, Django knows how to do the time conversion (as does postgres) - we just need to figure out if we want just a straight-up note on their profile, or if we want to do something more complicated, like use that time offset to then do adjustments.

[BethanyG]

For a profile image, I know some services use gravitar, which is pretty straightforward. Github works, too...for GitHub members.

As long as we don't have to deal with managing the files (and the image+url are clean of any malicious code), AND the image is the "correct" size for the GUI...yeah...external would be the easiest.

[lpatmo]

we need to maybe open a different issue for the whole "user wants to change their profile"

Ahh, you're totally right re: password resetting; I somehow forgot to log that. I don't think we need to return it in the GET request, necessarily; the user could click on a "Reset password" link, get an email with a link to a unique page, and then reset their password without seeing their old password. (Hacker News does this, for example.) But it's also a separate issue from this one.

we could go a few directions on timezone

Thanks for listing out those options. :D To me it sounds like the first option (getting it from the user's browser) might be the easiest. If so, will file a ticket to implement that on the front-end. (And then it could be saved on the profile in a PATCH request.)

---

In summary, the tickets I'll need to log:

[ ] Password reset support (user inputs their email on a form; they are sent a link to a page to reset their password)
[ ] On front-end, identify user's timezone and push the value into a timezone field so the user can save it on their profile
[ ] Make sure the /users/{user_id} endpoint supports PATCH so user can later edit it

First step is getting the /users/{user_id} GET endpoint up, though. (And that's this ticket.)

Does that sound right to you?