[WIP] Feature/profile page - requests for comments

[ccoenen]

(moved over from hackmdio/codimd#952 )

I am currently implementing a profile page that would let you edit your display name (henceforth: name) and possibly edit your password. It is far from finished, and I did a little bit of groundwork for future pages along the way. Those should get their own pull requests, probably.)

Questions:

• Does EJS have a way to detect used but unset variables (like a strict mode for EJS, perhaps)?
• We could put "delete user" on that page instead of the index-page-menu. Opinions? I think it's decided that it should go into profile.

TODO:

• The header contains everything and the kitchen sink from the note editor. This needs to be fixed
• user name will have to be sanitized. I would hate to restrict it to [a-z] (even though this would strictly not be a regression, it does feel like one). I have no experience with express/sequelize/ejs, so I would value your input - even just in form of documentation or a how-to, so I don't introduce XSS or something like that.
• the password change is not implemented at all.
• make sure I didn't mess up any of the login providers along the way (i.e. disable password boxes for ldap or github ...)
• migration should pre-fill username / displayname fields for existing users

-----8<---- MVP line, cut here if neccessary ---8<----

• (rudimentary) visual styling (right now, this is intended for code critique and conceptual work. Styling will be done later, of course.)
• translations should be added to the correct jsons
• username + displayname (display name defaulting to username, username defaulting to whatever it would have been so far. Perhaps the profile json will no longer be neccessary)
• have /user/:username actually use username instead of user.id
• documents i contributed and document I own is a bit tricky, those should be opt-in since they make documents discoverable that would otherwise have remained hidden. (checked off for "won't be done for now")
• move "delete" and "export" functionality into user profile

For a MVP we could "just not link to it, yet" but already deploy it. We could get some feedback this way and improve it more before we officially ship it.

[ccoenen]

(original comment by @SISheogorath hackmdio/codimd#952 (comment) )

We could put "delete user" on that page instead of the index-page-menu. Opinions?

Definitely! It was only put into the menu on the main page, because there was no profile page yet.

Did I get all the places, where those variables are used? Does EJS have a way to detect used but unset variables (like a strict mode for EJS, perhaps)?

Not sure if you got all, but EJS will definitely complain when there is something missing.

---

All in all, I really like your work! Seems like user profiles are moving forward! And I'm really curious about what we will get as result!

[ccoenen]

(original comment by @davidmehren hackmdio/codimd#952 (comment) )

How does this interact with users from other auth sources, eg. LDAP? Normal apps might not have permission to change user attributes or delete them.

[ccoenen]

(original comment by @SISheogorath hackmdio/codimd#952 (comment) )

@davidmehren right now, we delete all user data that exist in CodiMD's database when someone requests an account deletion. This means they can definitely re-auth with their external credentials afterwards, but they start from scratch, like their account never existed before.

Just realized you referred to the editing of the attributes in CodiMD. Not sure if we want to restrict them. How do other application handle that? I think most of them simply allow to change these details. At least discourse and GitLab do so, as far as I can say.

[ccoenen]

(my comment originally posted here: hackmdio/codimd#952 (comment) )

Thanks for reminding me, until now i was only concerned with local users. I will add it to the TODO list. Since I use none of the other login providers, I'd value any input on that part. I might need to disable password change for those users, but display name (name attribute) ist completely local in any case. It's what will be listed in the "2 ONLINE" button top right, for example.

[ccoenen]

unresolved debate about length of user names can be found here: hackmdio/codimd#952 (review)

[ccoenen]

(my comment originally published here: hackmdio/codimd#952 (comment) )

I will be going for username / displayname next. Along the way I'll probably rebase this a few times, so previous discussion might end up folded up in github.

[HerHde]

I would rather set a minimum length of 1 for display names. But there are reasons to not limit anything ;-)
And why should we set a minimum of 3 chars for login-/usernames?

[cyroxx]

Is there anything that can be done to move things forward on this one?

[ccoenen]

I rebase this on top of the current master from time to time. I will not be able to do any meaningful work for the next four or five weeks on this, I'm afraid. But: anyone who wants to work on this is very welcome to do so! I'm on riot at least once a day and I'll gladly answer any questions there or in this pull request!

[ccoenen]

What would help me tremendously is testing the other login providers. I only use email login, so I haven't really tested yet if I interfered with the others in any way so far.

[SISheogorath]

@ccoenen Want to rebase to 2.0?

[ccoenen]

Yes, I'll do this. I think we should finish this one for 2.0 too. I will need some help with testing, but other than that this shouldn't be very problematic.

I can start working on that in a week or so.

[davidmehren]

While I agree that we should have a profile page in 2.0, I don't think we can move forward with this PR. The new frontend already started reimplementing a profile page and the proposed API includes (at least parts of) the relevant REST calls.

I'm really sorry to throw away all your work, but I don't see a feasible way to combine this code with the plans for 2.0. Of course, your input on implementing this feature in the new frontend and API is still very much appreciated.

[SISheogorath]

This work was not thrown away, as far as I know a lot of his was actually taken into consideration and worked with by the frontend team when they did their implementation :)