Account Management

---

**Dokku:** https://accountmanagement.dokku.hypothes.is

- [x] No tests for accountManagement directive
- [ ] No tests for backend changes
- [x] accountManagement directive needs to be moved to a controller
- [x] ~~Password updating doesn't seem to work~~ _(Fixed 2014-08-06)_
- [x] Account sheet needs to close on logout.
- [x] Nothing happens after a user account is disabled other than a success message.
- [x] Remove email update form (pending emails)
- [ ] Disable_user endpoint needs to return a 401 when the password is invalid
- [x] Clear out password fields on successful submission
- [ ] Use appropriate http error codes in update_profile responses.
- [ ] Return `"errors"` keys in error responses.

---

I'm taking the opportunity here to open this pull request for the account management branch so that both the code and the interface can be reviewed.

It's okay for this branch to still be considered a work in progress, and this PR will remain open as a place for discussion until it it's ready to be merged.

So this branch adds three new panels to the sidebar.

Settings:

![settings](https://cloud.githubusercontent.com/assets/47144/3386301/0f5f4056-fc73-11e3-87df-e6495c1e147b.png)

Profile:

![profile](https://cloud.githubusercontent.com/assets/47144/3386302/0f631910-fc73-11e3-9eac-a26a48f640ad.png)

Account:

![account](https://cloud.githubusercontent.com/assets/47144/3386300/0f5d2aa0-fc73-11e3-8d29-dae3f5a7f523.png)

@RawKStar77 if you've any thing to add, please do :)
Horus has an edit profile view and so the EditProfileForm is only needed if
we reeuse their controller like we do at /login.

This was the whole purpose of the view mapper: to use horus pages as ajax
and have both.

But I'd like to stop that. For the moment I don't care which way you do
things.

If we were to use angular on /login and the others we could drop deform,
pyramid_deform, deform_bootstrap...

If we reimplement the controller logic on the backend to use colander
without deform, placing the business logic of these views behind a sane API
that doesn't care how you extract the struct or serialize the response,
that would be a great improvement. I would want to contribute that to
pylons/horus which is a horus rewrite that no one has had time to pull
together. The issue is that the original, eventray/horus, doesn't offer
reusable logic that can work without deform and it sets headers and returns
redirects and things.
On Aug 6, 2014 7:12 AM, "Aron Carroll" <notifications@github.com> wrote:

> In h/auth/local/views.py:
>
> > +        pwd = appstruct['pwd']
> > +
> > +        # Password check
> > +        user = self.User.get_user(request, username, pwd)
> > +        if user:
> > +            user.activation_id = -1
> > +            self.db.add(user)
> > +            FlashMessage(self.request,
> > +                 _('User disabled'),
> > +                 kind='success')
> > +        else:
> > +            FlashMessage(self.request,
> > +                _('Invalid password.'),
> > +                kind='error')
> > +
> > +        return httpexceptions.HTTPFound(location=request.url)
>
> Okay cool, but it's worth bearing in mind that Horus looks like it was
> designed for web pages. We're not working with pages here, but an API so we
> may have to deviate from Horus conventions when providing API responses.
> Flash messages and redirects aren't very useful in these cases.
>
> But I agree that they should be consistent across the codebase.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/hypothesis/h/pull/1275/files#r15875707>.
>